Re: Indexes on low cardinality columns

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

In response to

Browse pgsql-performance by date

  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