Re: Proposal - Allow extensions to set a Plan Identifier

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-23 15:30:04
Message-ID: ac8d319f-2350-4c6b-9513-e7d6cc8d2d92@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2025-03-23 15:55:29 Re: AIO v2.5
Previous Message Fujii Masao 2025-03-23 15:15:11 Re: doc patch: wrong descriptions for dropping replication slots