Re: Proposal: Log inability to lock pages during vacuum - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Proposal: Log inability to lock pages during vacuum
Date
Msg-id 546105E9.4070305@BlueTreble.com
Whole thread Raw
In response to Re: Proposal: Log inability to lock pages during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Proposal: Log inability to lock pages during vacuum  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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
countersto that. Should we add the other counters from vacuum? That would be significantly more data.
 

Semi-related, we should probably be reporting stats from heap truncation.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Stephen Frost
Date:
Subject: Re: pg_background (and more parallelism infrastructure patches)