Re: Vacuum rate limit in KBps

On 01/23/2012 11:16 PM, Robert Treat wrote:
> I keep thinking Greg has mistaken happiness with the MB based info in
> the vacuum patch as being happy without the output format, when really
> it is all about increased visibility.

I haven't taken that as anything but evidence I'm at least moving in the
right direction. I'm relatively systematic about how I approach these
things nowadays: figure out what isn't being logged/accounted for yet,
add visibility to that thing, iterate on improving its behavior as
measured by that, then make the best sorts of behavior changes
automatic. This suggested feature change, moving around what I see as
the worst part of the tuning knob UI, is an initial attempt along step 3
in that path. There's still plenty of ongoing work adding more
visibility too.

To more quickly summarize the point I was trying to make, providing a
meter that trivially shows you good vs. bad is the almost same problem
as making it fully automatic. If you can measure exactly when something
needs to happen and how badly screwed up it is, that's the hard part of
knowing when to just go fix it. Right now, the autovacuum measure is
based on the percent of change to something. I don't think any improved
vacuum triggering will go somewhere useful unless it starts with a
better measure of how real-world bloat accumulates, which you cannot
extract from the data collected yet. The free space measurement thread
and the ideas that have mainly been bouncing between Jaime and Noah
recently on this subject are directly addressing that, the part that
I've found to be the single most useful additional thing to monitor. It
may not be obvious that's providing information that can be consumed by
autovacuum, but that was my intention for how these pieces will
ultimately fit together.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com