On 02/07/10 13:31, Bruce Momjian wrote: <blockquote cite="mid:201007020131.o621VWK08371@momjian.us" type="cite"><pre
wrap="">LeonardoF wrote: </pre><blockquote type="cite"><pre wrap="">I'm trying to find more docs that explain the
"improvements"of
bitmap indexes in other products... but most of what I've found
talks about bitmapAND/OR.... which is something that is very
cool, but that postgres already does even with btree indexes...
or index creation time/size, which are, for the moment, the only
things that I'm pretty confident the patch would actually provide. </pre></blockquote><pre wrap="">
I think a real limitation of on-disk bitmap indexes is that they are
only feable for low cardinality columns, while btree handles all column
types.
</pre></blockquote><font size="-1"><font face="Helvetica"><br /> I recall that for (some/most? of) those low
cardinalitycases, (on disk) bitmap indexes would perform better too. I think the size saving alone is a huge win for
seriousdata warehousing situations. On the other hand problems I recall are possibly reduced UPDATE/DELETE performance
andissues 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).<br /><br /> regards<br /><br /> Mark<br /></font></font>
