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   http://www.enterprisedb.com
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to