MIME-Version: 1.0
References: 
 <CANWCAZYzx7a7E9AY16Jt_U3+GVKDADfgApZ-42SYNiig8dTnFA@mail.gmail.com>
 <a2ca34fd-7693-4406-9250-2f3435353001@gmail.com>
In-Reply-To: <a2ca34fd-7693-4406-9250-2f3435353001@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
Date: Thu, 13 Nov 2025 11:01:18 +0700
Message-ID: 
 <CANWCAZbwX5wb+pCU8hTQYonDAqBhQt5ZH7EP8cQL7O107fYoKg@mail.gmail.com>
Subject: Re: tuple radix sort
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Peter Geoghegan <pg@bowt.ie>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZbwX5wb%2BpCU8hTQYonDAqBhQt5ZH7EP8cQL7O107fYoKg%40mail.gmail.com>
Precedence: bulk

On Wed, Nov 12, 2025 at 9:28=E2=80=AFPM David Geier <geidav.pg@gmail.com> w=
rote:
> I've also been looking into radix sort the last days to accelerate GIN
> index builds. Ordering and removing duplicates requires a fast sort in
> generate_trgm().

If that's the case then I suggest first seeing if dfd8e6c73ee made
things any worse. A simpler possible improvement is to use a similar
normalization step for the chars, if needed, then do the sort and
quinique with a specialization for unsigned chars. (We don't yet
specialize qunique, but that can be remedied). If you're interested,
please start a separate thread for that.

> What would be great is if we could build a generic radix sort
> implementation, similarly to sort_template.h that can be used in other
> places. We would have to think a bit about the interface because instead
> of a comparator we would require some radix extraction callback.

That's moving the goalposts too far IMO. I want to get to a place
where I feel comfortable with the decisions made, and that already
requires a lot of testing. Also, I don't want to risk introducing
abstractions that make future improvements to tuplesort more
cumbersome.

--
John Naylor
Amazon Web Services