Re: Proposal - Allow extensions to set a Plan Identifier
От | Andrei Lepikhov |
---|---|
Тема | Re: Proposal - Allow extensions to set a Plan Identifier |
Дата | |
Msg-id | a22b23db-0047-4b55-bf1a-a84bb190b56e@gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal - Allow extensions to set a Plan Identifier (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: Proposal - Allow extensions to set a Plan Identifier
|
Список | 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
В списке pgsql-hackers по дате отправления: