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? http://www.postgresql.org/docs/faq
