To: Greg Stark <gsstark@mit.edu>
Cc: Andrew Sullivan <ajs@crankycanuck.ca>, pgsql-sql@postgresql.org
Subject: Re: row-attribute in EXPLAIN-output doesn't match count(*) 
In-reply-to: <87fyxsehmz.fsf@stark.xeocode.com> 
References: <200504141838.14705.andreak@officenet.no>
	<425EA496.2030501@archonet.com>
	<200504141921.38476.andreak@officenet.no>
	<20050414173358.GB9027@phlogiston.dyndns.org>
	<8764ypf8hy.fsf@stark.xeocode.com> <27509.1113521169@sss.pgh.pa.us>
	<87fyxsehmz.fsf@stark.xeocode.com>
Comments: In-reply-to Greg Stark <gsstark@mit.edu>
	message dated "15 Apr 2005 01:25:08 -0400"
Date: Fri, 15 Apr 2005 01:48:34 -0400
Message-ID: <29943.1113544114@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Greg Stark <gsstark@mit.edu> writes:
> So vacuum doesn't really know what tuples are actually visible to the
> snapshots actually taken by a transaction? It's making the conservative
> estimate that a snapshot could have been taken as early as the start of the
> transaction even if no snapshot was taken until later?

Not quite, because what it looks at is the snapshot xmin, which each
backend publishes in the PGPROC array.  A backend that has started a
transaction but hasn't yet set its snapshot can be recognized.

IIRC the problem comes up indirectly, because such a backend affects
the xmins that are computed by *other* transactions.  What VACUUM is
actually using as the cutoff is the least xmin that it can see anywhere
in PGPROC --- and everyone else's xmin will be no higher than the XID
of the laggard, even if the laggard hasn't yet set its own xmin.

Thinking about this, it seems like xmin might not be quite the right
metric for this purpose.  It might be worth thinking about whether we
could do better with a little more info in PGPROC.

			regards, tom lane