Re: Proposal: Log inability to lock pages during vacuum

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Proposal: Log inability to lock pages during vacuum
Дата
Msg-id 546105E9.4070305@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Proposal: Log inability to lock pages during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Proposal: Log inability to lock pages during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pg_background (and more parallelism infrastructure patches)