Re: vacuum, performance, and MVCC - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: vacuum, performance, and MVCC
Date
Msg-id 200606251627.k5PGRAU03585@momjian.us
Whole thread Raw
In response to Re: vacuum, performance, and MVCC  (Hannu Krosing <hannu@skype.net>)
Responses Re: vacuum, performance, and MVCC  (Jan Wieck <JanWieck@Yahoo.com>)
List 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 by date:

Previous
From: Daniel Xavier de Sousa
Date:
Subject: Re: Buffer for inner and outer table
Next
From: "Jonah H. Harris"
Date:
Subject: Re: vacuum row?