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 по дате отправления: