Re: vacuum, performance, and MVCC
От | Bruce Momjian |
---|---|
Тема | Re: vacuum, performance, and MVCC |
Дата | |
Msg-id | 200606251627.k5PGRAU03585@momjian.us обсуждение исходный текст |
Ответ на | Re: vacuum, performance, and MVCC (Hannu Krosing <hannu@skype.net>) |
Ответы |
Re: vacuum, performance, and MVCC
|
Список | pgsql-hackers |
Hannu Krosing wrote: > > > Maybe we could start from reusing the index tuples which point to > > > invisible tuples ? The index is not MVCC anyway, so maybe it is easier > > > to do in-place replacement there ? > > > > > > This probably has the same obstacles which have prevented us from > > > removing those in the first place (removing instead of marking as > > > invisible). Does it cause some locking issues ? Or does it go against > > > some other constraints of our index lookups ? > > > > > > I think that just setting the invisible bit in an index leaf node causes > > > nearly as much disk io as removing the node. > > > > > > If we could delete/reuse old index tuples, it would solve a sizable > > > chunk of index-growth problem, especially for cases where referenced key > > > value does not change. > > > > I think heap _and_ index reuse is the only useful direction. Index or > > heap reuse alone seems too marginal for the added complexity. > > Sure, but index reuse seems a lot easier, as there is nothing additional > to remember or clean out when doing it. Yes, seems so. TODO added: * Reuse index tuples that point to heap tuples that are not visible to anyone? > When reusing a heap tuple you have to clean out all index entries > pointing to it. Well, not for UPDATE for no key changes on the same page, if we do that. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: