On 6/13/24 14:59, Michael Paquier wrote:
> This will hopefully spark a discussion, and I was looking for answers
> regarding these questions:
> - Should the pgstat_kind_infos array in pgstat.c be refactored to use
> something similar to pgstat_add_kind?
> - How should the persistence of the custom stats be achieved?
> Callbacks to give custom stats kinds a way to write/read their data,
> push everything into a single file, or support both?
> - Should this do like custom RMGRs and assign to each stats kinds ID
> that are set in stone rather than dynamic ones?
It is a feature my extensions (which usually change planning behaviour)
definitely need. It is a problem to show the user if the extension does
something or not because TPS smooths the execution time of a single
query and performance cliffs.
BTW, we have 'labelled DSM segments', which allowed extensions to be
'lightweight' - not necessarily be loaded on startup, stay backend-local
and utilise shared resources. It was a tremendous win for me. Is it
possible to design this extension in the same way?
--
regards, Andrei Lepikhov
