Alternatives to very large tables with many performance-killing indicies? - Mailing list pgsql-general

From Wells Oliver
Subject Alternatives to very large tables with many performance-killing indicies?
Date
Msg-id CAOC+FBUSg2Lp+O5dcNxe+njGx0yGZ_RpokpgJ95fKbv6GnYO4w@mail.gmail.com
Whole thread Raw
Responses Re: Alternatives to very large tables with many performance-killing indicies?  (Merlin Moncure <mmoncure@gmail.com>)
Re: Alternatives to very large tables with many performance-killing indicies?  (Jeff Janes <jeff.janes@gmail.com>)
Re: Alternatives to very large tables with many performance-killing indicies?  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
Hey folks, a question. We have a table that's getting large (6 million rows right now, but hey, no end in sight). It's wide-ish, too, 98 columns.

The problem is that each of these columns needs to be searchable quickly at an application level, and I'm far too responsible an individual to put 98 indexes on a table. Wondering what you folks have come across in terms of creative solutions that might be native to postgres. I can build something that indexes the data and caches it and runs separately from PG, but I wanted to exhaust all native options first.

Thanks!

--
Wells Oliver
wellsoliver@gmail.com

pgsql-general by date:

Previous
From: Steve Crawford
Date:
Subject: Re: You cannot do PITR with streaming replication - true?
Next
From: Merlin Moncure
Date:
Subject: Re: Alternatives to very large tables with many performance-killing indicies?