On Thu, Jul 24, 2025 at 01:14:47PM -0500, Sami Imseih wrote: >> Sami Imseih <samims...@gmail.com> writes: >>>> That is not to say that I think 719dcf3c4 was a good idea: it looks >>>> rather useless from here. It seems to me that the right place to >>>> accumulate these sorts of stats is in CachedPlanSources, and I don't >>>> see how this helps. What likely *would* help is some hooks in >>>> plancache.c for pg_stat_statements to connect into so it can count >> >>> One possible hook for accumulating custom and generic plans per >>> queryId would be inside GetCachedPlan. However, this would require >>> calling pgss_store an extra time, in addition to ExecutorEnd, every time >>> GetCachedPlan is executed, which could introduce non-negligible >>> overhead.
I would suspect more contention on the PGSS locks in the prepared statement and/or extended query protocol case if we were to do that. With the amount of information we want to track in PGSS, which is that we want to know from where a plan is coming from (generic cache, custom cache or something else), FWIW I'm still OK with this information added in PlannedStmt itself to be able to link back to the state retrieved at the end of the executor because it's also cost-free. I'm also OK to be proved wrong based on arguments that could justify the addition of an extra hook, but I don't really see the use-cases that could justify such additions yet. Perhaps CachedPlanType is misnamed, though, would it be more suited to name that as a sort of "origin" or "source" field concept? We want to know which which source we have retrieved a plan that a PlannedStmt refers to. -- Michael
signature.asc
Description: PGP signature
