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

Re: plans for bitmap indexes?

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plans for bitmap indexes?
Date: 2004-10-26 20:53:44
Message-ID: 1098824023.2643.7.camel@fuji.krosing.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On T, 2004-10-26 at 18:42, Greg Stark wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> 
> > I repeat here my earlier proposal of making the bitmap indexes
> > page-level and clustering data automatically on AND of all defined
> > bitmap indexes. 
> 
> The problem with page-level bitmaps is that they could be much less effective.
> Consider a query like 'WHERE foo = ? AND bar = ? AND baz = ?" where each of
> those matches about 1% of your tuples. If you have 100 tuples per page then
> each of those bitmaps will find a tuple in about half the pages. So the
> resulting AND will find about 1/8th of the pages as candidates. In reality the
> number of pages it should have to fetch should be more like 1 in a million.
> 
> The other problem is that for persist on-disk indexes they require more work
> to update. You would have to recheck every other tuple in the page to
> recalculate the bit value instead of just being able to flip one bit.

Read again ;)

the per-page clustering would make sure that all the tuples would be on
1 (or on a few) pages.

and what comes to updating the index, you have to do it only once per
100 pages ;)

----------------
Hannu


In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2004-10-26 21:18:04
Subject: Re: plans for bitmap indexes?
Previous:From: Mark WongDate: 2004-10-26 20:52:06
Subject: DBT-3 Query 2 EXPLAIN ANALYZE differences

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