Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Ivan Bykov <I(dot)Bykov(at)modernsys(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
Date: 2025-03-14 01:50:55
Message-ID: 7660B369-CF3D-4914-881A-5A8F0558C85C@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Mar 14, 2025, at 8:15, Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>> FWIW, another idea I have on top of my mind is the addition of a
>> counter in JumbleState that we increment each time we enter
>> _jumbleNode(), then simply call JUMBLE_FIELD_SINGLE() after the
>> incrementation. And we can rely on this counter to be unique each
>> time we jumble a node..
>
> With this approach, the author of the custom function will need
> to remember to increment the counter, right?

Actually, no. _jumbleNode() is the unique entry point we use when jumbling a sub-Node in a bigger Node structure, so custom functions don’t need to touch it.

> Also, I am wondering what is the difference between appending an incrementing
> counter in JState vs just appending a constant for every node ( NULL
> or NOT NULL ) ?

Well, the problem is not NULL vs non-NULL, so..

Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Quan Zongliang 2025-03-14 02:14:35 Re: Available disk space per tablespace
Previous Message Sungwoo Chang 2025-03-14 01:46:58 dsm_registry: Add detach and destroy features