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
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? |