Re: bitmap indexes - performance
От | Mark Kirkwood |
---|---|
Тема | Re: bitmap indexes - performance |
Дата | |
Msg-id | 4C2DA391.5010502@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: bitmap indexes - performance (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: bitmap indexes - performance
|
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: