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