Ühel kenal päeval, E, 2006-06-26 kell 16:58, kirjutas Martijn van Oosterhout: > On Mon, Jun 26, 2006 at 10:50:26AM -0400, Bruce Momjian wrote: > > > > I suppose we would also change the index_getmulti() function to return > > > > a set of ctids plus flags so the caller knows to follow the chains, > > > > right? > > > > > > It is probably better to always return the pointer to the head of CITC > > > chain (the one an index points to) and do extra visibility checks and > > > chain-following on each access. This would keep the change internal to > > > tuple fetching functions. > > > > So index_getnext() traverses the chain and returns one member per call. > > Makes sense. Just realize you are in a single index entry returning > > multiple tuples. We will need some record keeping to track that. > > Yes, and for index_getmulti (which doesn't visit the heap at all) we'll > have to change all the users of that (which aren't many, I suppose). > It's probably worth making a utility function to expand them. > > I'm still confused where bitmap index scan fit into all of this. Is > preserving the sequential scan aspect of these a goal with this new > setup?
Bitmap index scan does not have to change much - only the function that gets tuple by its ctid must be able to trace forward chains within the page. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
