Re: Vacuum rate limit in KBps - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Vacuum rate limit in KBps
Date
Msg-id 4F20A9A8.7000106@2ndQuadrant.com
Whole thread Raw
In response to Re: Vacuum rate limit in KBps  (Robert Treat <rob@xzilla.net>)
List pgsql-hackers
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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Dominik Bylica
Date:
Subject: Psql names completion.
Next
From: Robert Haas
Date:
Subject: Re: show Heap Fetches in EXPLAIN for index-only scans