Message-ID: <a974fe71-3dc6-4c4f-95be-7ac5442674c0@gmail.com>
Date: Mon, 28 Jul 2025 09:11:36 +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>
Cc: Sami Imseih <samimseih@gmail.com>, 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: <1647760.1753369510@sss.pgh.pa.us>
 <CAA5RZ0sxC0=2wZ-QaRB7FdMmQ4_BYKG=X+gdDGHnS6KTrfgLQA@mail.gmail.com>
 <1673684.1753379027@sss.pgh.pa.us>
 <CAA5RZ0sQuoHJsGc-dJV15yYURuXsOp2pwr9hLAk+pcm7=MAK2w@mail.gmail.com>
 <aILaHupXbIGgF2wJ@paquier.xyz>
 <CAA5RZ0t54uP+O2dGZCoYfzOU_wcT2trVL65GdZB00RiLDs9BCg@mail.gmail.com>
 <1933906.1753462272@sss.pgh.pa.us>
 <CAA5RZ0t4A4PVLHK5DPZWCsZvtviLf==PGG5eiy6Bm0DCpchHyQ@mail.gmail.com>
 <aIcWKh8wK2GWFMFz@paquier.xyz>
 <CAMMNXX=xUr7uGRNc28rDNt-eNxtFS1tWLPArJy24C1S3Ed8SFw@mail.gmail.com>
 <aIccz3szRNC4_FUm@paquier.xyz>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <aIccz3szRNC4_FUm@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a974fe71-3dc6-4c4f-95be-7ac5442674c0%40gmail.com>
Precedence: bulk

On 28/7/2025 08:46, Michael Paquier wrote:
> On Mon, Jul 28, 2025 at 08:41:29AM +0200, Andrei Lepikhov wrote:
>> It looks good, but doesn't it seem too narrow?
> 
> For the use case of the thread which is to count the number of custom
> vs generic plans, it would be good enough.
Sure, no objections.
> 
>> This minor change allows an extension to track a specific query from
>> the parse tree up to the end of execution and carry as much data as
>> needed. The extension (pg_stat_statements as well) may add all the
>> necessary data in the parse hook, planner hook, or any of the
>> execution hooks. With a trivial naming convention, Extensible nodes of
>> different extensions will not interfere.
>> To identify the cached plan, the GetCachedPlan hook may be introduced.
> 
> Without knowing the actual use cases where these additions can be
> useful, introducing this extra amount of infrastructure may not be
> justified.  Just my 2c and my impressions after studying the whole
> thread.
The case is as I already described: in Postgres, extensions have no way 
to identify how their path hooks really influenced specific query plan 
and its execution. During planning, they have only a pointer to the 
Query structure, but at the end of execution, only a PlannedStmt is 
available. I propose improving this 'blind' approach to planning.
The only argument I usually receive in response to such a proposal is to 
add a beneficial example. The current pg_stat_statements change may be a 
good example of the employment of such infrastructure, isn't it?

-- 
regards, Andrei Lepikhov