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: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Improvement of procArray.xmin for VACUUM
Date: 2007-03-27 00:29:04
Message-ID: 877it3leb3.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


I have a question about what would happen for a transaction running a command
like COPY FROM. Is it possible it would manage to arrange to have no live
snapshots at all? So it would have no impact on concurrent VACUUMs? What about
something running a large pg_restore?

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> On the whole though I think we should let this idea go till 8.4;

I tend to agree but for a different reason. I think it's something that will
open the doors for a lot of new ideas. If we put it in CVS HEAD early in 8.4 I
think (or hope at any rate) we'll think of at least a few new things we can do
with the new more precise information it exposes.

Just as an example, if you find you have no live snapshots can you throw out
the combocid hash? Any tuple you find with a combocid that's been discarded
that way must predate your current scan and therefore is deleted for you.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-03-27 00:50:48 Re: Improvement of procArray.xmin for VACUUM
Previous Message Bruce Momjian 2007-03-26 23:44:54 Re: Improvement of procArray.xmin for VACUUM