| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
| Subject: | Re: track generic and custom plans in pg_stat_statements |
| Date: | 2025-07-28 06:46:39 |
| Message-ID: | aIccz3szRNC4_FUm@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stepan Neretin | 2025-07-28 06:57:10 | Re: [PATCH] avoid double scanning in function byteain |
| Previous Message | Andrei Lepikhov | 2025-07-28 06:41:29 | Re: track generic and custom plans in pg_stat_statements |