Re: Improvement of procArray.xmin for VACUUM

From: "Simon Riggs" <simon(at)2ndquadrant(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-26 19:37:16
Message-ID: 1174937836.6069.436.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Sat, 2007-03-24 at 11:48 -0400, Tom Lane wrote:

> Also, at some point a long-running transaction becomes a bottleneck
> simply because its XID is itself the oldest thing visible in the
> ProcArray and is determining everyone's xmin. How much daylight is
> there really between "your xmin is old" and "your xid is old"?

Hmm, yes. How often do we have an LRT that consists of multiple
statements of significant duration? Not often, I'd wager.

How much does it cost to optimise for this case?

Did Heikki's patch to move the xmin forward during VACUUM get rejected?
That seems like it has a much wider use case.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-03-26 19:40:29 Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
Previous Message Simon Riggs 2007-03-26 19:27:11 Re: Improvement of procArray.xmin for VACUUM