Re: [Proposal] Adding callback support for custom statistics kinds
| От | Michael Paquier |
|---|---|
| Тема | Re: [Proposal] Adding callback support for custom statistics kinds |
| Дата | |
| Msg-id | aSOidfDnBT4lbtHp@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: [Proposal] Adding callback support for custom statistics kinds (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: [Proposal] Adding callback support for custom statistics kinds
|
| Список | pgsql-hackers |
On Wed, Nov 19, 2025 at 08:10:43PM -0600, Sami Imseih wrote: > It just occurred to me that the documentation [0] should be > updated to describe the callbacks. I will do that in the next > revision. > > [0] https://www.postgresql.org/docs/current/xfunc-c.html#XFUNC-ADDIN-CUSTOM-CUMULATIVE-STATISTICS Hmm. Based on what I can read from the patch, you are still enforcing file name patterns in the backend, as of: + extra->statfiles[i] = psprintf("%s/pgstat.%d.%d.stat", + PGSTAT_STAT_PERMANENT_DIRECTORY, kind, i); My take (also mentioned upthread) is that this design should go the other way around, where modules have the possibility to define their own file names, and some of them could be generated on-the-fly when writing the files, for example for a per-file database split, or the object ID itself. The important part for variable-numbered stats is that the keys of the entries have to be in the main pgstats file. Then, the extra data is loaded back based on the data in the entry key, based on a file name that only a custom stats kind knows about (fd and file name). It means that the custom stats kind needs to track the files it has to clean up by itself in this scheme. We could pass back to the startup process some fds that it cleans up, but it feels simpler here to let the custom code do what they want, instead, rather than having an array that tracks the file names and/or their fds. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: