On Thu, Jul 04, 2024 at 10:11:02AM +0700, Andrei Lepikhov wrote: > 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.
Yeah, I can get that. pgstat.c is quite good regarding that as it delays stats flushes until commit by holding pending entries (see the pgStatPending business for variable-size stats). Custom stats kinds registered would just rely on these facilities, including snapshot APIs, etc. > 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? I am not sure how this would be useful when it comes to cumulative statistics, TBH. These stats are global by design, and especially since these most likely need to be flushed at shutdown (as of HEAD) and read at startup, the simplest way to achieve that to let the checkpointer and the startup process know about them is to restrict the registration of custom stats types via _PG_init when loading shared libraries. That's what we do for custom WAL RMGRs, for example. I would not be against a new flag in KindInfo to state that a given stats type should not be flushed, as much as a set of callbacks that offers the possibility to redirect some stats kinds to somewhere else than pgstat.stat, like pg_stat_statements. That would be a separate patch than what's proposed here. -- Michael
signature.asc
Description: PGP signature
