Re: Alternatives to very large tables with many performance-killing indicies?

From: Jasen Betts <jasen(at)xnet(dot)co(dot)nz>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Alternatives to very large tables with many performance-killing indicies?
Date: 2012-08-18 07:12:20
Message-ID: k0nf8k$5vv$1@reversiblemaps.ath.cx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2012-08-16, Wells Oliver <wellsoliver(at)gmail(dot)com> wrote:
> --0023543336c685451c04c7683ffb
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.

get rid of some of the columns ?

--
⚂⚃ 100% natural

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bartel Viljoen 2012-08-18 08:05:02 Schemas vs partitioning vs multiple databases for archiving
Previous Message Raghavendra 2012-08-18 05:24:24 Re: Fwd: PSQL Help from your biggest fan