Re: Inaccuracy in VACUUM's tuple count estimates

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

> Assuming that Kevin's describing his needs correctly, we could resolve
> this by inventing HEAPTUPLE_INSERT_AND_DELETE_IN_PROGRESS.  VACUUM could
> assume that that's a probably-dead tuple, while SSI could do something
> different.

That could work.

On the other hand, the old code, where such a transaction showed as
HEAPTUPLE_DELETE_IN_PROGRESS, might still work for predicate.c as
long as it's clear that this return code sometimes means "insert
and delete are both in progress and the insert might commit without
committing the delete".  Those conditions could be identified
within predicate.c; although it seems like that would involve
duplicating some work which was already in HTSV, with the usual
costs and risks of duplicate code.

> I'm not sure if it's worth special-casing xmin == xmax,
> where the tuple is guaranteed to never be of interest to any other
> transaction?

That could be checked in predicate.c.  I see no reason to create a
separate return code for it if it's not of interest for other
callers.  It could even be left as a later optimization, since a
false positive serialization failure doesn't compromise
correctness, but it seems like it is probably easy enough to cover
to just do so now.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company