Re: Publish autovacuum informations

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Publish autovacuum informations
Дата
Msg-id 56D6034B.7030202@dalibo.com
обсуждение исходный текст
Ответ на Re: Publish autovacuum informations  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Publish autovacuum informations  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 01/03/2016 20:29, Jim Nasby wrote:
> On 3/1/16 8:37 AM, Julien Rouhaud wrote:
>>> >
>>> >We understood (IMHO is an interesting idea) but as Michael said
>>> hooks is
>>> >for a general purpose. So can you demonstrate other use cases for this
>>> >new hooks?
>>> >
>> I can think of several usage.  First, since the hook will always be
>> called, an extension will see all the activity a worker is doing when
>> exposing private structure will always be some kind of sampling.  Then,
> 
> I think that's pretty key. If you wanted to create an extension that
> logs vacuums (which would be great, since current state of the art is
> logs + pgBadger), you'd want to gather your data about what the vacuum
> did as the vacuum was ending.
> 

Indeed these information are missing. I guess that'd be possible by
adding (or moving) a hook in lazy_vacuum_rel() that provide access to
part or all of the LVRelStats and rusage informations.

> I can certainly see cases where you don't care about that and just want
> what's in shared memory, but that would only be useful for monitoring
> what's happening real-time, not for knowing what final results are.
> 
> BTW, I think as much of this as possible should also work for regular
> vacuums.
> 

You mean for database wide vacuum?

>> you can have other information that wouldn't be available just by
>> exposing private structure.  For instance knowing a VACUUM isn't
>> performed by the worker (either because another worker is already
>> working on it or because it isn't needed anymore). IIRC there was a
>> discussion about concurrency issue in this case. We can also know if the
>> maintenance was cancelled due to lock not obtained fast enough.
>> Finally, as long as the hooks aren't use, they don't have any overhead.
>>   I agree that all this is for monitoring purpose.
>>
>> I'm not sure what are the fancy things that Michael had in mind with
>> exposing the private structure.  Michael, was it something like having
>> the ability to change some of these data through an extension?


-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Addition of extra commit fest entry to park future patches
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: psql completion for ids in multibyte string