On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
> On 11/10/14, 12:15 PM, Andres Freund wrote:
> >>>If what we want is to quantify the extent of the issue, would it be more
> >>>convenient to save counters to pgstat? Vacuum already sends pgstat
> >>>messages, so there's no additional traffic there.
> >I'm pretty strongly against that one in isolation. They'd need to be
> >stored somewhere and they'd need to be queryable somewhere with enough
> >context to make sense. To actually make sense of the numbers we'd also
> >need to report all the other datapoints of vacuum in some form. That's
> >quite a worthwile project imo - but*much* *much* more work than this.
>
> We already report statistics on vacuums
> (lazy_vacuum_rel()/pgstat_report_vacuum), so this would just be adding
> 1 or 2 counters to that. Should we add the other counters from vacuum?
> That would be significantly more data.
At the very least it'd require:
* The number of buffers skipped due to the vm
* The number of buffers actually scanned
* The number of full table in contrast to partial vacuums
I think it'd require a fair amount of thinking about which values are
required to make sense of the number of skipped buffers due to not being
able to acquire the cleanup lock.
If you want to do this - and I sure don't want to stop you from it - you
should look at it from a general perspective, not from the perspective
of how skipped cleanup locks are logged.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services