public inbox for [email protected]
help / color / mirror / Atom feedFrom: Greg Stark <[email protected]>
To: Drouvot, Bertrand <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: shared-memory based stats collector - v70
Date: Thu, 18 Aug 2022 15:26:31 -0400
Message-ID: <CAM-w4HNm06PcCM40-kY+jLgD_Tqjr3ymBy8qErfOvWqQyJE+6Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAM-w4HN=4ss5dS2DH6Cof=zocJXeGOjRNKxEGgUZdJPMndyNzA@mail.gmail.com>
<CAAKRu_Z18jYbarKA4GZMOO00KtUqKtBqgQ8SgB=wSvSqKq3iiA@mail.gmail.com>
<[email protected]>
<CAM-w4HOxaO6iJ94bGt1A65PRgX_b4gGSmb4mdzakZ1QhvGW=jA@mail.gmail.com>
<[email protected]>
<CAM-w4HMhHAxjpXNVMZ5WhULHpd3+LuP27zaSKSFnzZeRwHZTjg@mail.gmail.com>
<[email protected]>
<CAM-w4HNqCR7X9q5_wbJi4wLfTT1gLvy5VRS+ZGo6z8-DbXkHpw@mail.gmail.com>
<[email protected]>
<CAM-w4HP_YL8uPrNiv2DPKmq1KD3QLEX7CBLc5DCJ9j7mf7eerw@mail.gmail.com>
<[email protected]>
<CAM-w4HPGq_rpZAW4p71+d90oykyi9y7PgiQ1c9_ROs+WROCjuQ@mail.gmail.com>
<[email protected]>
<CAM-w4HNLtcKxrG0WepCKjt5tizbvZRcrqABX=jNNZoi_18E5rw@mail.gmail.com>
<[email protected]>
On Thu, 18 Aug 2022 at 02:27, Drouvot, Bertrand <[email protected]> wrote:
>
> 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.
And indexes of course. It's a bit frustrating since without the
catalog you won't know what table the index actually is for... But
they're pretty important stats.
On that note though... What do you think about having the capability
to add other stats kinds to the stats infrastructure? It would make a
lot of sense for pg_stat_statements to add its entries here instead of
having to reimplement a lot of the same magic. And I have in mind an
extension that allows adding other stats and it would be nice to avoid
having to reimplement any of this.
To do that I guess more of the code needs to be moved to be table
driven from the kind structs either with callbacks or with other meta
data. So the kind record could contain tupledesc and the code to
construct the returned tuple so that these functions could return any
custom entry as well as the standard entries.
--
greg
view thread (82+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: shared-memory based stats collector - v70
In-Reply-To: <CAM-w4HNm06PcCM40-kY+jLgD_Tqjr3ymBy8qErfOvWqQyJE+6Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox