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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
