Re: tuple radix sort
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Peter Geoghegan <pg@bowt.ie>
Date: 2025-11-13T04:01:18Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Skip common prefixes during radix sort
- f6bd9f0fe25a 19 (unreleased) landed
-
Perform radix sort on SortTuples with pass-by-value Datums
- ef3c3cf6d021 19 (unreleased) landed
On Wed, Nov 12, 2025 at 9:28 PM David Geier <geidav.pg@gmail.com> wrote: > 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