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
