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) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
