Re: VACUUM/ANALYZE counting of in-doubt tuples

Tom Lane wrote:

> I feel fairly comfortable with this analysis for ANALYZE, and the
> patch I posted yesterday can easily be adjusted to accommodate it.
> However, what of VACUUM?  As that code stands, every non-removable
> tuple (including RECENTLY_DEAD ones) is counted as live, and the
> dead-tuples count gets reset to zero.  That seems clearly bogus.
> But the other-transaction-commits-second hypothesis seems a good bit
> more dubious for VACUUM than it is for ANALYZE.
> 
> Should we attempt to adjust VACUUM's accounting as well, or leave it
> for 8.4?  For that matter, should adjusting ANALYZE be left for 8.4?
> Thoughts?

Has this issue been a real problem?  If so, probably we should consider
adjusting ANALYZE for 8.3 per your proposal.

For VACUUM, I think one thing we should do to reduce the severity of the
problem is to send the pgstat message before attempting the truncation;
that way, less transactions are lost.  (There is still going to be a lot
of lost pgstat traffic when vacuum_delay is high).  I am not sure about
further changes.

For 8.4 we could discuss more invasive changes.  Maybe send a pgstat
message just before each vacuum_delay sleep point?  This would have to
use the incremental update approach, which is probably better when
vacuum_delay is enabled.

-- 
Alvaro Herrera                  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended."  (Gerry Pourwelle)