Re: shared-memory based stats collector - v70
От | Drouvot, Bertrand |
---|---|
Тема | Re: shared-memory based stats collector - v70 |
Дата | |
Msg-id | 7f622949-2d78-c030-e7e0-cdee5f6cf79b@amazon.com обсуждение исходный текст |
Ответ на | Re: shared-memory based stats collector - v70 (Greg Stark <stark@mit.edu>) |
Ответы |
Re: shared-memory based stats collector - v70
|
Список | pgsql-hackers |
Hi, On 8/17/22 9:46 PM, Greg Stark wrote: > On Tue, 16 Aug 2022 at 08:49, Drouvot, Bertrand <bdrouvot@amazon.com> wrote: >> >> + if (p->key.kind != PGSTAT_KIND_RELATION) >> + continue; > Hm. So presumably this needs to be extended. Either to let the caller > decide which types of stats to return or to somehow return all the > stats intermixed. In my monitoring code I did the latter because I > didn't think going through the hash table repeatedly would be very > efficient. But it's definitely a pretty awkward API since I need a > switch statement that explicitly lists each case and casts the result. What I had in mind is to provide an API to retrieve stats for those that would need to connect to each database individually otherwise. That's why I focused on PGSTAT_KIND_RELATION that has PgStat_KindInfo.accessed_across_databases set to false. I think that another candidate could also be PGSTAT_KIND_FUNCTION. I think that's the 2 cases where a monitoring tool connected to a single database is currently missing stats related to databases it is not connected to. So what about 2 functions? one to get the stats for the relations and one to get the stats for the functions? (And maybe a view on top of each of them?) Regards, -- Bertrand Drouvot Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: