| 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: | Whole Thread | Raw Message | 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 |