From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Lukas Fittl <lukas(at)fittl(dot)com> |
Subject: | Re: Proposal - Allow extensions to set a Plan Identifier |
Date: | 2025-03-22 05:48:41 |
Message-ID: | Z95POXvrfESUgVAD@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 21, 2025 at 09:25:24AM -0400, Sami Imseih wrote:
>> planner() is the sole place in the core code where the planner hook
>> can be called. Shouldn't we have at least a call to
>> pgstat_report_plan_id() after planning a query? At least that should
>> be the behavior I'd expect, where a module pushes a planId to a
>> PlannedStmt, then core publishes it to the backend entry in non-force
>> mode.
>
> I agree. I was just thinking we rely on the exec_ routines to report the plan_id
> at the start. But, besides the good reason you give, reporting
> (slightly) earlier is
> better for monitoring tools; as it reduces the likelihood they find an empty
> plan_id.
Yep. pgstat_report_plan_id() is not something that extensions should
do, but they should report the planId in the PlannedStmt and let the
backend do the rest.
> Overall, v3 LGTM
Thanks. If anybody has any objections and/or comments, now would be a
good time. I'll revisit this thread at the beginning of next week.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2025-03-22 06:23:13 | Re: Using read_stream in index vacuum |
Previous Message | David G. Johnston | 2025-03-22 05:23:56 | Re: Make COPY format extendable: Extract COPY TO format implementations |