From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <gsstark@mit.edu>
Cc: Andrew Sullivan <ajs@crankycanuck.ca>
Cc: pgsql-sql@postgresql.org
Subject: Re: row-attribute in EXPLAIN-output doesn't match count(*)
Date: Fri, 15 Apr 2005 01:48:34 -0400
Message-ID: <29943.1113544114@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, gsstark@mit.edu, ajs@crankycanuck.ca
Subject: Re: row-attribute in EXPLAIN-output doesn't match count(*)
In-Reply-To: <29943.1113544114@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox