From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Vikul Khosla <vkhosla(at)gridsolv(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Indexes on low cardinality columns |
Date: | 2009-10-17 21:24:40 |
Message-ID: | f67928030910171424m6ced73eake60727cd31e716f9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, Oct 17, 2009 at 10:02 AM, Vikul Khosla <vkhosla(at)gridsolv(dot)com> wrote:
>
> Thanks Greg!.
>
> Yes, we do need to query on all 3000 values ... potentially. Considering
> that when we changed the B-Tree indexes to Bitmap indexes in Oracle
> we saw a huge performance boost ... doesn't that suggest that absence of
> this
> feature in PG is a constraint ?
Was the bitmap index in Oracle used all by itself, or was it used in
concert with other bitmaps (either native bitmap indexes or a bitmap
conversion of a non-bitmap index) to produce the speed up?
> Are there any other clever workarounds to boosting performance involving
> low queries on low cardinality columns ? i.e avoiding a full table scan ?
Have you tired setting enable_seqscan=off to see what plan that
produces and whether it is faster or slower? If it is better, then
lowering random_page_cost or increasing cpu_tuple_cost might help
motivate it to make that decision without having to resort to
enable_seqscan. Of course tuning those setting just to focus on one
query could backfire rather badly.
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Volker Grabsch | 2009-10-17 22:58:16 | Calculation of unused columns |
Previous Message | Robert Haas | 2009-10-17 17:33:56 | Re: Indexes on low cardinality columns |