On 12/10/21 18:40, Tom Lane wrote:
> Andrey Lepikhov <a.lepikhov@postgrespro.ru> writes:
>> But core jumbling code is good, fast and much easier in support.
> A bigger issue is that query ID stability isn't something we are going
> to promise on a large scale --- for example, what if a new release adds
> some new fields to struct Query? So I'm not sure that "query IDs should
> survive dump/reload" is a useful goal to consider. It's certainly not
> something that could be reached by anything even remotely like the
> existing code.
Thank you for the explanation.
I think the problem of queryId is that is encapsulates two different
meanings:
1. It allows an extension to match an query on post parse and execution
stages. In this sense, queryId should be as unique as possible for each
query.
2. For pg_stat_statements purposes (and my project too) it represents an
query class and should be stable against permutations of range table
entries, clauses, e.t.c. For example:
"SELECT * FROM a,b;" and "SELECT * FROM b,a;" should have the same queryId.
This issue may be solved in an extension with next approach:
1. Force as unique value for queryId as extension wants in a post parse hook
2. Generalize the JumbleQuery routine code to generate a kind of query
class signature.
The attached patch is a first sketch for such change.
--
regards,
Andrey Lepikhov
Postgres Professional