Are these improvements (index creation time, index size) worth enough
to keep on working on this?
I mean: given that bitmaps don't give any benefits in query times, but
only benefits related to disk size and bulk index creation times, and
will have horrible performance for insertions/deletions: would this job be
worthed?
In case it is: I will try to clean up the patch and post it...
Well, if you can fix the more basic missing stuff, I think we could live
with the performance issues. Bitmaps would still be a huge win for
relatively static tables with lots of low-cardinality columns (basic
data warehouse case).
If I recall correctly, the old patch was still missing both WAL and
VACUUM support. These would be required before tradeoffs of space vs.
update performance would be worth talking about.
As a side note: I guess that most of the bitmap indexes performance
improvements in the SELECT area are already implemented in postgres
in the bitmapand/or and bitmap scan stuff? I couldn't find any docs that
say that bitmap indexes are faster for selects, unless of course they
are ANDed/ORed together (which is something postgres already does
for regular btree indexes)
Have you tested this? The bitmap AND/OR for btrees in current postgres
isn't exactly cost-free, especially the recheck. It seems like there
could be room for better performance with bitmap indexes.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
