Re: track generic and custom plans in pg_stat_statements

On 31/7/2025 02:09, Michael Paquier wrote:
> On Wed, Jul 30, 2025 at 03:09:08PM -0500, Sami Imseih wrote:
>>> In practice, with this knowledge, we can access the CachedPlanSource of
>>> the corresponding PREPARED statement via an extension and override the
>>> decision made in 'auto' mode. Unfortunately, we cannot obtain a pointer
>>> to plan cache entries for plans prepared by the extended protocol, but
>>> this may be possible in the future.
>>>
>>> So, I meant that the source of the plan is one important characteristic,
>>> and the type (custom or generic) is another, independent characteristic
> 
> It seems to me that we're going to need a bit more than a design
> concept here, explaining how this can be useful for core to provide
> this knowledge to extensions.  A lot of concepts can be defined as
> "useful", but it's hard to evaluate what you'd want here and how much
> it can be useful in terms of manipulations of the cached plans
> depending on what you may aim for.  It's also unclear up to which
> extent the current state of the code would be able to help in the
> concepts you're describing.  Anyway, I am not inclined to have pointer
> references in structures pointing to other parts of the system, just
> because these can be "useful".
Don't mind, I also think it wasn't a great idea to save a pointer.
After the discussion, I came up with the idea that an 'extended list' in 
some key nodes is a much more helpful and flexible way, serving multiple 
purposes.
Anyway, the extensibility model has never been an easy part of the 
system to design. So, let's think about that as a first draft approach.

-- 
regards, Andrei Lepikhov