MIME-Version: 1.0
References: <89742024-d51a-c66b-90b9-67f837072cd2@joeconway.com>
 <CAD21AoAyPVYZ_6VAQCOanvHTL3CRSqTDCFrtvaYVGwOQbrnxgQ@mail.gmail.com>
 <CABwTF4VzMJaTLrpYtBj4n9r73TFjffzqpPFeUmJPrkY6cmHEAg@mail.gmail.com>
 <3b1683bc-2630-a0d0-6083-8a45aa1b54bf@joeconway.com>
 <cda17e6d-f625-b45e-dfb9-8d18ed09ecc5@joeconway.com>
 <5dc12198-80ff-4e70-b187-11ef33418411@enterprisedb.com>
 <12f6d0f0-0b5d-46e3-afa9-c35bd418d49f@joeconway.com>
 <Zpia8GwTB9turihT@paquier.xyz>
In-Reply-To: <Zpia8GwTB9turihT@paquier.xyz>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Tue, 24 Mar 2026 16:05:23 +0800
Message-ID: 
 <CABPTF7V++TBbzH7+FyKKsjy0RR4S_CLfBJypeM8KgjZ_RUiaCw@mail.gmail.com>
Subject: Re: RFC: pg_stat_logmsg
To: Michael Paquier <michael@paquier.xyz>
Cc: Joe Conway <mail@joeconway.com>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Gurjeet Singh <gurjeet@singh.im>, Masahiko Sawada <sawada.mshk@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABPTF7V%2B%2BTBbzH7%2BFyKKsjy0RR4S_CLfBJypeM8KgjZ_RUiaCw%40mail.gmail.com>
Precedence: bulk

Hi,

On Thu, Jul 18, 2024 at 12:33=E2=80=AFPM Michael Paquier <michael@paquier.x=
yz> wrote:
>
> On Wed, Jul 17, 2024 at 07:43:13AM -0400, Joe Conway wrote:
> > On 7/16/24 18:14, Tomas Vondra wrote:
> >> As for the feature, I've never done a fleet-wide analysis, so if this =
is
> >> one of the main use cases, I'm not really sure I can judge if this is =
a
> >> good tool for that. It seems like it might be a convenient way to do
> >> that, but does that require we add the module to contrib?
> >
> > I had an offlist chat with Andres about this IIRC and he suggested he
> > thought it ought to be just built in to the backend as part of the
> > statistics subsystem. Lately though I have been toying with the idea of
> > keeping it as an extension and basing it off Michael Paquier's work for
> > Pluggable cumulative statistics.
>
> This may live better as a contrib/ module, serving as well as an extra
> template for what can be done with the pluggable stats.  Adding that
> in core is of course OK for me if that's the consensus.  The APIs for
> pluggable stats are really the same as what you would store in core,
> minus the system functions you'd want to add in the catalog .dat
> files, of course.
>
> I'd like to get it this part done by the end of this commit fest to
> have room with pg_stat_statements for this release, but well, we'll
> see.  As far as I can see everybody who commented on the thread seems
> kind of OK with the idea to fix the stats kinds IDs in time, like
> custom RMGRs.  That's just simpler implementation-wise, but I'm also
> looking for more opinions.
>
> > Hmm, yeah, I had been planning to include postgres version as part of t=
he
> > output, but maybe it would need to be part of the key.
>
> Seems to me that you should do both, then: add PG_VERSION to the
> entries, and hash the keys with it for uniqueness.  You could also
> have a reset function that performs a removal of the stats for
> anything else than the current PG_VERSION, for example.
> --
> Michael


This feature seems both interesting and useful, yet it hasn't
progressed for some time. Looking at the thread history, the patch
stalled around 2023 in part because the pluggable cumulative
statistics infrastructure was still under development, which offered
an opportunity to rework it on top of framework primitives rather than
carrying DIY implementations of shared hash tables, persistence, and
reset logic.

The refactoring opportunity is now basically available. The relevant
infrastructure landed in stages:

7949d9594582 (Aug 2024) =E2=80=94 kind registration, dshash routing, flush_=
pending_cb
c06e71d1aca (Nov 2024) =E2=80=94 write_to_file flag, enabling opt-in persis=
tence
4ba012a8ed9 (Dec 2025) =E2=80=94 to_serialized_data / from_serialized_data =
/
finish callbacks

I=E2=80=99m considering picking this up and 'd like to move it forward. Bef=
ore
doing so, I am curious about whether there was a consensus on putting
it into core or keeping it as an extension, and whether there are any
major blockers I might have overlooked.


Best,
Xuneng