Re: vacuum, performance, and MVCC
От | Martijn van Oosterhout |
---|---|
Тема | Re: vacuum, performance, and MVCC |
Дата | |
Msg-id | 20060626145844.GI24611@svana.org обсуждение исходный текст |
Ответ на | Re: vacuum, performance, and MVCC (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: vacuum, performance, and MVCC
Re: vacuum, performance, and MVCC |
Список | pgsql-hackers |
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? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: