Re: Proposal - Allow extensions to set a Plan Identifier

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