Re: Pluggable cumulative statistics

> On Fri, Jun 21, 2024 at 01:28:11PM +0900, Michael Paquier wrote:
> On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> >> * The kind IDs may change across restarts, meaning that any stats data
> >> associated to a custom kind is stored with the *name* of the custom
> >> stats kind. Depending on the discussion happening here, I'd be open
> >> to use the same concept as custom RMGRs, where custom kind IDs are
> >> "reserved", fixed in time, and tracked in the Postgres wiki. It is
> >> cheaper to store the stats this way, as well, while managing conflicts
> >> across extensions available in the community ecosystem.
> >
> > I prefer to avoid having a central database if possible.
>
> I was thinking the same originally, but the experience with custom
> RMGRs has made me change my mind. There are more of these than I
> thought originally:
> https://wiki.postgresql.org/wiki/CustomWALResourceManagers

From what I understand, coordinating custom RmgrIds via a wiki page was
made under the assumption that implementing a table AM with custom WAL
requires significant efforts, which limits the demand for ids. This
might not be same for custom stats -- I've got an impression it's easier
to create one, and there could be multiple kinds of stats per an
extension (one per component), right? This would mean more kind Ids to
manage and more efforts required to do that.

I agree though that it makes sense to start this way, it's just simpler.
But maybe it's worth thinking about some other solution in the long
term, taking the over-engineered prototype as a sign that more
refactoring is needed.