Horton

Re: Proposal - Allow extensions to set a Plan Identifier

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Lukas Fittl <lukas@fittl.com>
Date: 2025-03-22T05:48:41Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow plugins to set a 64-bit plan identifier in PlannedStmt

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