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

Re: Bitmap index thoughts

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: swm(at)linuxworld(dot)com(dot)au, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bitmap index thoughts
Date: 2007-02-02 00:28:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Where are we on this patch?  Does it have performance tests to show
where it is beneificial?  Is it ready to be reviewed?


Heikki Linnakangas wrote:
> I've been skimming through the bitmap index patch...
> A scan needs to access at least five pages:
> 1. B-tree index (root+others, depending on depth)
> 2. The auxiliary heap page
> 3. bitmap index meta page
> 4. LOV page
> 5. bitmap page
> That seems like a lot of indirection. A high startup cost is probably ok 
> for typical bitmap index use cases and most of the needed pages should 
> stay in memory, but could we simplify this? Why do we need the auxiliary 
> heap, couldn't we just store the blk+offset of the LOV item directly in 
> the b-tree index item?
> And instead of having separate LOV pages that store a number of LOV 
> items, how about storing each LOV item on a page of it's own, and using 
> the rest of the page to store the last chunk of the bitmap. That would 
> eliminate one page access, but more importantly, maybe we could then get 
> rid of all the bm_last_* attributes in BMLOVItemData that complicate the 
> patch quite a bit, while preserving the performance.
> -- 
>    Heikki Linnakangas
>    EnterpriseDB
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Gavin SherryDate: 2007-02-02 00:34:49
Subject: Re: Bitmap index thoughts
Previous:From: Jeremy DrakeDate: 2007-02-01 21:20:18
Subject: writing new regexp functions

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