Re: vacuum, performance, and MVCC
От | Hannu Krosing |
---|---|
Тема | Re: vacuum, performance, and MVCC |
Дата | |
Msg-id | 1151334958.3885.33.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: vacuum, performance, and MVCC (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
Ü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
В списке pgsql-hackers по дате отправления: