On 11/25/2011 08:39 AM, Alvaro Herrera wrote:
I was about to commit this when I noticed that the avg values may not be all that representative of reality after all; consider that it's computed across the whole duration of the vacuuming operation, including the index scans ... it'd be possibly useful to keep separate timings for the heap scan (which is likely to use I/O more quickly) from index scans. That way you can tune for the max, not a possibly misleading average. That's a much larger change though, so I'm not going to get into it.
Yes, that's one of the interesting additional things to track. At the point I was writing this originally, things like "Single Pass VACUUM" were still on the table; maybe it still is. Didn't seem worthwhile to try and get any more detailed than the average when the underlying work might still be whacked around. Just having some useful numbers on both costs and speeds for the first time was such an improvement I didn't want to get too far lost on chasing perfection here, at the risk of not getting anything done.
One funny thing in the test I did was that the buffer count might add to a much larger amount than total disk pages:
Good catch, I didn't think about the ramifications of multi-pass work here. I'll revisit that and see if I can do a bit better before the final 9.2 CommitFest; I'm not done with this area yet. I kind of needed this basic logging patch in place before it's easy to experiment with behavior changes and see what they do though.
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
