Re: row-attribute in EXPLAIN-output doesn't match count(*)

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> We have to start the transaction no later than event #2 since there has
> to be something to hold the lock. But it'd be easy enough to decouple
> this from BEGIN, and it'd be good enough to solve the "COMMIT;BEGIN"
> problem.

Oh I think I finally figured out what you're saying here.

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?

> Which of these three times do you think now() ought to correspond to?
> I recall having argued that it should be event #3 since that corresponds
> to the database snapshot you see. 100% backwards compatibility would
> require setting now() at event #1, but will anyone weep if we change that?

I think it would be weird to perform a select and see records with dates after
now(). It would also be weird to perform a select and not see records inserted
before now(). I'm not sure any of the above guarantees those criteria for READ
COMMITTED mode, but I think I'm on the same general path as you.

--
greg