On 3/23/25 01:01, Michael Paquier wrote:
On Sat, Mar 22, 2025 at 11:50:06PM +0100, Andrei Lepikhov wrote:
planId actually looks less controversial than queryId or plan_node_id. At
the same time, it is not free from the different logic that extensions may
incorporate into this value: I can imagine, for example, the attempt of
uniquely numbering plans related to the same queryId, plain hashing of the
plan tree, hashing without constants, etc.
One plan ID should have one single query ID,
I'm not sure I understand what do you mean by that. QueryId reflects
syntactic structure of the query, but planId - semantics. For example:
SELECT relname FROM pg_class JOIN pg_am USING (oid);
SELECT relname FROM pg_am JOIN pg_class USING (oid);
have different queryIds: -6493293269785547447 and 4243743071053231833
but the same plan:
Hash Join
Hash Cond: (pg_class.oid = pg_am.oid)
-> Seq Scan on pg_class
-> Hash
-> Seq Scan on pg_am
You can invent multiple other cases here - remember query tree
transformations we made before optimisation.
but the opposite may be
not necessarily true: a query ID could be associated with multiple
plan patterns (aka multiple plan IDs). What this offers is that we
know about which plan one query is currently using in live, for a
given query ID.
Okay, as I've said before, it seems practical. I just worry because I
see that people don't understand that queryId is a more or less
arbitrary value that may or may not group queries that differ only by
constants to a single "Query Class". I think the same attitude will be
paid to planId. It is okay for statistics. However, non-statistical
extensions need more guarantees and want to put different logic into
these values.
For now, we have examples of only statistical extensions in open-source
and may live with a proposed solution.
So, it seems that extensions may conflict with the same field. Are we sure
that will happen if they are loaded in different orders in neighbouring
backends?
Depends on what kind of computation once wants to do, and surely
without some coordination across the extensions you are using these
cannot be shared, but it's no different from the concept of a query
ID.
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?
--
regards, Andrei Lepikhov
