Message-ID: <84510f52-ffc1-4e27-a906-883f4bd777c7@gmail.com>
Date: Thu, 31 Jul 2025 09:16:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: track generic and custom plans in pg_stat_statements
To: Michael Paquier <michael@paquier.xyz>, Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Sabino Mullane <htamfids@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Nikolay Samokhvalov <nik@postgres.ai>,
 Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
References: <1933906.1753462272@sss.pgh.pa.us>
 <CAA5RZ0t4A4PVLHK5DPZWCsZvtviLf==PGG5eiy6Bm0DCpchHyQ@mail.gmail.com>
 <aIcWKh8wK2GWFMFz@paquier.xyz>
 <CAA5RZ0t6GctNqFA60_ajhw0D+9DeuHYa7F2QCQMumTxx=h3UZQ@mail.gmail.com>
 <CAA5RZ0sYd6-KeQqR4uLFS1swBh37jKJCzR_E-G373EuLKm5UzA@mail.gmail.com>
 <aInHvKN4Gsztmopy@paquier.xyz>
 <87249b23-c4c5-4c0b-88d3-efb13b8a04d1@gmail.com>
 <CAA5RZ0sgLNBKUdceqvoxNCbn9rirJhH6bUjAmSZB6557cbcG4Q@mail.gmail.com>
 <b3b87daa-d610-424d-8217-bc4a47dd918c@gmail.com>
 <CAA5RZ0t-5LjHFsYML49Dg=gt97GJbMs1zVGi86YDmvsa4=oGFw@mail.gmail.com>
 <aIq0KgnwY_GW6IPC@paquier.xyz>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <aIq0KgnwY_GW6IPC@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/84510f52-ffc1-4e27-a906-883f4bd777c7%40gmail.com>
Precedence: bulk

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