Skip site navigation (1) Skip section navigation (2)

Re: bitmap indexes - performance

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: bitmap indexes - performance
Date: 2010-07-02 08:30:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 02/07/10 13:31, Bruce Momjian wrote:
> Leonardo F wrote:
>> 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.
> 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.

I recall that for (some/most? of) those low cardinality cases, (on disk) 
bitmap indexes would perform better too. I think the size saving alone 
is a huge win for serious data warehousing situations. On the other hand 
problems I recall are possibly reduced UPDATE/DELETE performance and 
issues 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).



In response to


pgsql-hackers by date

Next:From: uwcssaDate: 2010-07-02 11:59:56
Subject: hello
Previous:From: Magnus HaganderDate: 2010-07-02 08:16:15
Subject: Re: server authentication over Unix-domain sockets

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group