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
