Thanks Greg!.
Yes, we do need to query on all 3000 values ... potentially. Considering
we saw a huge performance boost ... doesn't that suggest that absence of this
From: Greg Stark <gsstark@mit.edu>
To: Vikul Khosla <vkhosla@gridsolv.com>
Cc: pgsql-performance@postgresql.org
Sent: Fri, October 16, 2009 8:27:15 PM
Subject: Re: [PERFORM] Indexes on low cardinality columns
On Fri, Oct 16, 2009 at 4:36 PM, Vikul Khosla <
vkhosla@gridsolv.com> wrote:
> In Oracle, we replaced the B-Tree Indexes with Bitmap indexes and saw
> performance go
> through the roof. I know Postgres does not have Bitmap indexes,
> but is there a reasonable alternative to boost performance in situations
> where low cardinality
> columns are involved ?
Do you need to query on all of the 3,000 values?
If it's just particular values which are common i would suggest using
partial indexes on some other column with a where clause restricting
them to only one value in the low-cardinality column. But I wouldn't
want to have 3,000 indexes.
Alternately you could try partitioning the table, though 3,000
partitions is a lot too. If you often update this value then
partitioning wouldn't work well anyways (but then bitmap indexes
wouldn't have worked well in oracle either)
--
greg
--
Sent via pgsql-performance mailing list (
pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
