From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Vikul Khosla <vkhosla(at)gridsolv(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Indexes on low cardinality columns |
Date: | 2009-10-17 01:27:15 |
Message-ID: | 407d949e0910161827wb9e7e4cyd25faae8d895a74e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Oct 16, 2009 at 4:36 PM, Vikul Khosla <vkhosla(at)gridsolv(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | decibel | 2009-10-17 03:51:50 | Re: UUID as primary key |
Previous Message | Vikul Khosla | 2009-10-16 23:36:57 | Indexes on low cardinality columns |