From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pluggable cumulative statistics |
Date: | 2024-07-04 23:27:12 |
Message-ID: | Zocv0Hxo0UZ_C0L0@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 04, 2024 at 02:00:47PM -0700, Andres Freund wrote:
> On 2024-06-13 16:59:50 +0900, Michael Paquier wrote:
>> * Making custom stats data persistent is an interesting problem, and
>> there are a couple of approaches I've considered:
>> ** Allow custom kinds to define callbacks to read and write data from
>> a source they'd want, like their own file through a fd. This has the
>> disadvantage to remove the benefit of c) above.
>
> I am *strongly* against this. That'll make it much harder to do stuff like not
> resetting stats after crashes and just generally will make it harder to
> improve the stats facility further.
>
> I think that pluggable users of the stats facility should only have control
> over how data is stored via quite generic means.
I'm pretty much on the same line here, I think. If the redo logic is
changed, then any stats kinds pushing their stats into their own file
would need to copy/paste the same logic as the main file. And that's
more error prone.
I can get why some people would get that they don't want some stats
kinds to never be flushed at shutdown or even read at startup. Adding
more callbacks in this area is a separate discussion.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-07-04 23:28:33 | Re: Pluggable cumulative statistics |
Previous Message | Michael Paquier | 2024-07-04 23:18:33 | Re: pgsql: Add pg_get_acl() to get the ACL for a database object |