Re: Publish autovacuum informations
От | Jim Nasby |
---|---|
Тема | Re: Publish autovacuum informations |
Дата | |
Msg-id | 56D5ED99.9010501@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Publish autovacuum informations (Julien Rouhaud <julien.rouhaud@dalibo.com>) |
Ответы |
Re: Publish autovacuum informations
|
Список | 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
В списке pgsql-hackers по дате отправления: