On Thu, Feb 13, 2025 at 11:10:27AM -0600, Sami Imseih wrote: > I don't think direct setting of values is a good idea. We will need an API > similar to pgstat_report_query_id which ensures we are only reporting top > level planIds -and- in the case of multiple extensions with the capability > to set a planId, only the first one in the stack wins. pgstat_report_query_id > does allow for forcing a queryId ( force flag which is false by default ), and > I think this new API should allow the same.
Yep. The main idea behind that is to offer to extensions one single and consistent way to set this kind of data. In short, we have use cases where we want to be able to associate an ID with a plan tree, we're not sure which algorithm would be the best one to use in core. One thing that we are sure about is that there is no easy way to figure out through the planner hook across multiple extensions if this has been set with an in-core structure. Sure, you can do that with a shmem area associated to one of the extensions, but it seems just easier to plug in a set/get logic into core, including a way to force setting the ID? The key point to me is to add that to the backend entry structure and a plan node structure, so as it is possible to track that through the planner hook for the planner structure. The backend entry is for monitoring, not really pg_stat_activity first. I'm obviously siding with this proposal because we have an ask to track this kind of data, and because this kind of data is kind of hard to track across a stack of extensions through the core backend code. Point is, would others be interested in this addition or just object to it because it touches the core code? -- Michael
signature.asc
Description: PGP signature
