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)
