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

Re: vacuum, performance, and MVCC

From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>,"Jan Wieck" <JanWieck(at)Yahoo(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>,"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-26 12:34:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> > >When you are using the update chaining, you can't mark that index
> > >as dead because it actually points to more than one row on the
> > >some are non-visible, some are visible.
> > 
> > Back up the truck ... you mean in the current code base we have heap

> > tuples that are visible in index scans because of heap tuple
> > but without index tuples pointing directly at them?
> I don't know where this idea came from, but it's not true.  
> All heap tuples, dead or otherwise, have index entries.  

When using CITC you would be "reusing" the index tuples from the current
heap tuple, so you can only reuse free space or a dead member of a CITC
You cannot reuse a dead tuple not member of a CITC chain because that
has separate
(invalid) index tuples pointing at it.

Part of the trick was moving slots (==ctid) around, so I still do not
really see how
you can represent the CITC chain as part of the update chain. 
Unless you intend to break dead parts of the update chain ? Maybe that
is ok ?


In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-06-26 12:43:04
Subject: Re: libpq Describe Extension [WAS: Bytea and perl]
Previous:From: Bruce MomjianDate: 2006-06-26 11:17:31
Subject: Re: vacuum, performance, and MVCC

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