Re: Proposal - Allow extensions to set a Plan Identifier

Поиск
Список
Период
Сортировка
От Andrei Lepikhov
Тема Re: Proposal - Allow extensions to set a Plan Identifier
Дата
Msg-id ac8d319f-2350-4c6b-9513-e7d6cc8d2d92@gmail.com
обсуждение исходный текст
Ответ на Re: Proposal - Allow extensions to set a Plan Identifier  (Sami Imseih <samimseih@gmail.com>)
Ответы Re: Proposal - Allow extensions to set a Plan Identifier
Список 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



В списке pgsql-hackers по дате отправления: