Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id aIccz3szRNC4_FUm@paquier.xyz
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
List pgsql-hackers
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.

> 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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements
Next
From: Stepan Neretin
Date:
Subject: Re: [PATCH] avoid double scanning in function byteain