Re: shared-memory based stats collector - v70 - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: shared-memory based stats collector - v70
Date
Msg-id 7f622949-2d78-c030-e7e0-cdee5f6cf79b@amazon.com
Whole thread Raw
In response to Re: shared-memory based stats collector - v70  (Greg Stark <stark@mit.edu>)
Responses Re: shared-memory based stats collector - v70
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: Peter Smith
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply