From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: row-attribute in EXPLAIN-output doesn't match count(*) |
Date: | 2005-04-15 05:48:34 |
Message-ID: | 29943.1113544114@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Greg Stark <gsstark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rizal | 2005-04-15 06:33:55 | Salam Kenal |
Previous Message | Dinesh Pandey | 2005-04-15 05:35:46 | EXCEPTION handling in PL/pgSQL. |