From: Andrei Lepikhov <lepihov@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: 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: Mon, 28 Jul 2025 09:11:36 +0200
Message-ID: <a974fe71-3dc6-4c4f-95be-7ac5442674c0@gmail.com> (raw)
In-Reply-To: <aIccz3szRNC4_FUm@paquier.xyz>
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>
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
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: <a974fe71-3dc6-4c4f-95be-7ac5442674c0@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