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

Re: Improvement of procArray.xmin for VACUUM

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Improvement of procArray.xmin for VACUUM
Date: 2007-03-25 18:51:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Well I think this would be the same infrastructure we would need to do
>> the other discussed improvement to address pg_dump's impact. That
>> would require us to publish the youngest xmax of the live
>> snapshots. Vacuum could deduce that that xid cannot possibly see any
>> transactions between the youngest extant xmax and the oldest
>> in-progress transaction.
> ... and do what with the knowledge?  Not remove tuples, because any such
> tuples would be part of RECENTLY_DEAD update chains that that xact might
> be following now or in the future.

Well that just means it might require extra work, not that it would be

Firstly, some tuples would not be part of a chain and could be cleaned up
anyways. Others would be part of a HOT chain which might make it easier to
clean them up.

But even for tuples that are part of a chain there may be solutions. We could
truncate the tuple to just the MVCC information so subsequent transactions can
find the head. Or we might be able to go back and edit the forward link to
skip the dead intermediate tuples (and somehow deal with the race

  Gregory Stark

In response to

pgsql-patches by date

Next:From: ITAGAKI TakahiroDate: 2007-03-26 00:46:47
Subject: Re: Load distributed checkpoint V3
Previous:From: Hannu KrosingDate: 2007-03-25 18:18:19
Subject: Re: LIKE optimization in UTF-8 and locale-C

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