Re: bitmap indexes - performance - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: bitmap indexes - performance
Date
Msg-id 4C2E99BA.3080009@catalyst.net.nz
Whole thread Raw
In response to Re: bitmap indexes - performance  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-hackers
On 02/07/10 20:30, Mark Kirkwood wrote:
>
> I recall that for (some/most? of) those low cardinality cases, (on 
> disk) bitmap indexes would perform better too. I think the size saving 
> alone is a huge win for serious data warehousing situations. On the 
> other hand problems I recall are possibly reduced UPDATE/DELETE 
> performance and issues with CREATE INDEX CONCURRENTLY and also 
> complications with VACUUM (altho these last two may have been sorted - 
> I've lost touch with what was in the most recent patches).
>
>

Sorry, missed the message earlier where Bruce mentioned VACUUM.

Re Performance, I definitely recall some pretty serious performance 
improvements on some of the TPC D (or H) queries when the dataset was 
large . However I am wondering if most of the improvement might have 
been because the bitmap index(es) fitted in memory and the corresponding 
btree ones did not.

Leonardo - maybe try larger datasets (20M rows probably means table and 
btree indexes can all fit in memory). Also might be worth experimenting 
with the TPC D,H dataset and query generator and seeing if any of those 
queries tickle any bitmap sweet spot.


Cheers

Mark



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Allow copydir() to be interrupted.
Next
From: Tom Lane
Date:
Subject: Re: _bt_parent_deletion_safe() isn't safe