Re: Proposal - Allow extensions to set a Plan Identifier

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Proposal - Allow extensions to set a Plan Identifier
Date: 2025-03-25 09:42:57
Message-ID: a22b23db-0047-4b55-bf1a-a84bb190b56e@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/25/25 00:47, Sami Imseih wrote:
> I know it was mentioned above by both Michael and Andrei that
> AppendJumble should not be exposed. I am not sure I agree with
> that. I think it should be exposed, along with
> JUMBLE_FIELD, JUMBLE_FIELD_SINGLE and JUMBLE_STRING
> and _jumbleList.
It would be helpful if you could provide an example to support the
reasoning behind exposing this stuff. I assume you want to influence the
logic of jumbling, correct? If that’s the case, it might be beneficial
to add a callback to the JumbleState that is triggered during each node
jumbling attempt. This could facilitate moving clocations code and data
into pg_stat_statements and give developers the opportunity to influence
the jumbling process, adding extra meaning to their hashes.
One reason this might be necessary is that generating the same hash for
both a Param node and a Const node could lead to a more generalized
hash, allowing us to group more queries under the same value.

--
regards, Andrei Lepikhov

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-03-25 09:52:31 RE: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.
Previous Message Ashutosh Bapat 2025-03-25 09:35:55 Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning