Re: Publish autovacuum informations

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, <fabriziomello(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Publish autovacuum informations
Date: 2016-03-01 19:29:29
Message-ID: 56D5ED99.9010501@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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 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?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2016-03-01 19:36:35 Re: PROPOSAL: Fast temporary tables
Previous Message Pavel Stehule 2016-03-01 19:27:09 Re: PROPOSAL: Fast temporary tables