Horton

Re: Proposal - Allow extensions to set a Plan Identifier

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Lukas Fittl <lukas@fittl.com>
Date: 2025-03-23T15:30:04Z
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 3/23/25 15:56, Sami Imseih wrote:
>> Hmm, queryId generation code lies in the core and we already came to
>> terms that this field has only a statistical purpose. Do you want to
>> commit planId generation code?
> 
> But, extensions don't necessarily need to rely on the core queryId. They
> can generate their own queryId.
> We have it documented for compute_query_id as such [0]
> "Note that an external module can alternatively be used if the in-core query
> identifier computation method is not acceptable"
In theory they don't, but in practice they must.
This mess especially boring because one of problematic extensions at the 
same time the most popular one - pg_stat_statements. People forget to 
follow strict instructions about load order of extensions and think it 
is the extension instability when one of their query plans isn't 
captured, but should.
So, it may be not an issue in a cloud provider predefined installations, 
but a headache for custom configurations.

-- 
regards, Andrei Lepikhov