Re: bitmap indexes - performance

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