From: Andrei Lepikhov <lepihov@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Nikolay Samokhvalov <nik@postgres.ai>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Subject: Re: track generic and custom plans in pg_stat_statements
Date: Thu, 31 Jul 2025 09:16:35 +0200
Message-ID: <84510f52-ffc1-4e27-a906-883f4bd777c7@gmail.com> (raw)
In-Reply-To: <aIq0KgnwY_GW6IPC@paquier.xyz>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: lepihov@gmail.com, michael@paquier.xyz, samimseih@gmail.com, tgl@sss.pgh.pa.us, htamfids@gmail.com, nik@postgres.ai, ilya.evdokimov@tantorlabs.com
Subject: Re: track generic and custom plans in pg_stat_statements
In-Reply-To: <84510f52-ffc1-4e27-a906-883f4bd777c7@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox