| 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: | Whole Thread | Raw Message | 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
| 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 |