Skip site navigation (1) Skip section navigation (2)

Re: vacuum, performance, and MVCC

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-25 17:09:35
Message-ID: 449EC34F.6000004@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 6/25/2006 12:27 PM, Bruce Momjian wrote:

> 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.
> 

An update that results in all the same values of every indexed column of 
a known deleted invisible tuple. This reused tuple can by definition not 
be the one currently updated. So unless it is a table without a primary 
key, this assumes that at least 3 versions of the same row exist within 
the same block. How likely is that to happen?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2006-06-25 17:30:45
Subject: Re: vacuum, performance, and MVCC
Previous:From: Jan WieckDate: 2006-06-25 17:02:05
Subject: Re: vacuum, performance, and MVCC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group