| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [Proposal] Adding callback support for custom statistics kinds |
| Date: | 2025-10-24 00:57:38 |
| Message-ID: | CAA5RZ0ufpEdVaiLYMyFN-NXO6F7y45-0ciyvkbO6Tvz3pnb1=g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Thu, Oct 23, 2025 at 04:35:58PM -0500, Sami Imseih wrote:
> > Perhaps if someone wants to have separate files for each different
> > types of data,
> > we should be able to support multiple files. I think we can add an
> > option for the
> > number of files and they can then be named "pgstat.<kind>.1.stat",
> > pgstat.<kind>.2.stat",
> > etc. I rather avoid having the extension provide a set of files names.
> > So as arguments to the callback, besides the main file pointer ( as
> > you mention below),
> > we also provide the list of custom file pointers.
> >
> > what do you think?
>
> My worry here is the lack of flexibility regarding stats that could be
> split depending on the objects whose data needs to be flushed. For
> example, stats split across multiple databases (like our good-old
> pre-v14 pgstats, but on a per-kind basis). So I don't think that we
> can really assume that the list of file names should be fixed when we
> begin the read/write process of the main pgstats file.
I was trying to avoid an extra field in PgStat_KindInfo if possible, but
it's worthwhile to provide more flexibility to an extension. I will go
with this.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2025-10-24 01:11:20 | Re: Skipping schema changes in publication |
| Previous Message | Ranier Vilela | 2025-10-24 00:51:14 | Avoid handle leak (src/bin/pg_ctl/pg_ctl.c) |