Re: bitmap indexes - performance

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-hackers(at)postgresql(dot)org
Cc: m_lists(at)yahoo(dot)it
Subject: Re: bitmap indexes - performance
Date: 2010-07-03 02:00:26
Message-ID: 4C2E99BA.3080009@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-07-03 02:02:59 Re: _bt_parent_deletion_safe() isn't safe
Previous Message Igor Kryltsov 2010-07-03 01:55:38 Table partitioning - is anything coming?