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

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Bykov Ivan <i(dot)bykov(at)modernsys(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
Date: 2025-03-14 01:15:34
Message-ID: CAA5RZ0sv0ChY8iVYbO4uLr_RLWBpEhJm7RyabJpgH3iEeP1VOg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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?

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 ) ?

appending some constant or null-term to the hash:
<expression 1> <0><expression 2> <0> <0>

vs

appending an incremented value:
expression_1 <1> expression_2 <2> <3>

Both will do the job of adding the required entropy

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2025-03-14 01:19:43 Re: Add contrib/pg_logicalsnapinspect
Previous Message Euler Taveira 2025-03-14 00:54:40 Re: Separate GUC for replication origins