Re: plans for bitmap indexes? - Mailing list pgsql-hackers

From Yann Michel
Subject Re: plans for bitmap indexes?
Date
Msg-id 20041014210854.GA6742@zoom.spline.inf.fu-berlin.de
Whole thread Raw
In response to Re: plans for bitmap indexes?  (Chris Browne <cbbrowne@acm.org>)
Responses Re: plans for bitmap indexes?
List pgsql-hackers
Hi,

On Sat, Oct 09, 2004 at 01:31:36PM -0400, Chris Browne wrote:
> 
> The most nearly comparable thing is be the notion of "partial
> indexes," where, supposing you had 60 region codes (e.g. - 50 US
> states, 10 Canadian provinces), you might set up indices thus:
> 
[...]
> 
> The partial indexes will not ALWAYS be useful; in cases where they
> aren't, it is not inconceivable that there are improvements to be made
> in the query optimizer...

So what you are suggesting here is the "tree-fashioned-static way" of
real bitmap indexes. I.E. each time a new value is inserted vor any kind
of thus indexes column you have to create a new index which is not very
usefull as you can think of. In addition nothing about the real
granularity is known to the optimizer to let it guess the best execution
plan, i.e. to do a full table scan or use an index. That means if one
attributes value is representative for 80 percent it is usefull to do a
full table scan whereas if its value is representative for only 5
percent the index might be better. But as I understood the partial index
concept, no statistics for "value representation" are available.

Therefore I started to do read some articles and books about bitmap
index implementations to maby contribute... we will see...

BTW: Is there any more documented CVS-version available? I mean it would
be really nice to read some comments from time to time or at least more
comments about each function/method's purpose or functionality.

Regards,
Yann


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #1270: stack overflow in thread in fe_getauthname
Next
From: Alvaro Herrera
Date:
Subject: Re: plans for bitmap indexes?