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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
