Re: Improvement of procArray.xmin for VACUUM - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Improvement of procArray.xmin for VACUUM
Date
Msg-id 1174937836.6069.436.camel@silverbirch.site
Whole thread Raw
In response to Re: Improvement of procArray.xmin for VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improvement of procArray.xmin for VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Improvement of procArray.xmin for VACUUM  (Bruce Momjian <bruce@momjian.us>)
List 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



pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM
Next
From: Tom Lane
Date:
Subject: Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch