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.
