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

Re: Improvement of procArray.xmin for VACUUM

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-26 20:01:41
Message-ID: 200703262001.l2QK1fC27346@momjian.us (view raw or flat)
Thread:
Lists: pgsql-patches
Simon Riggs wrote:
> 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?

Zero cost.  It involves just tracking if there are any old snapshots,
and if not, update the proc xmin rather than skipping the asignment,
like we do now.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-26 20:25:32
Subject: Re: Improvement of procArray.xmin for VACUUM
Previous:From: Tom LaneDate: 2007-03-26 19:44:27
Subject: Re: Improvement of procArray.xmin for VACUUM

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