On Tue, Aug 23, 2022 at 9:18 AM David Rowley <dgrowle...@gmail.com> wrote: > > I have the following dimensions in mind for consideration: > > 1. Specialisations to handle sorting of non-null datums (eliminates > checking for nulls in the comparison function) > 2. Specialisations to handle single column sorts (eliminates > tiebreaker function call or any checks for existence of tiebreaker) > 3. ASC sort (No need for if (ssup->ssup_reverse) > INVERT_COMPARE_RESULT(compare)) > > If we did all of the above then we'd end up with 3 * 2 * 2 * 2 = 24 > specialization functions. That seems a bit excessive. So here I'd > like to discuss which ones we should add, if any. > > I've attached a very basic implementation of #1 which adds 3 new > functions for sorting non-null datums.
Did you happen to see https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com where I experimented with removing all null handling? What I had in mind was pre-partitioning nulls and non-nulls when populating the SortTuple array, then calling qsort twice, once with the non-null partition with comparators that assume non-null, and (only if there are additional sort keys) once on the null partition. And the pre-partitioning would take care of nulls first/last upfront. I haven't looked into the feasibility of this yet, but the good thing about the concept is that it removes null handling in the comparators without additional sort specializations. -- John Naylor EDB: http://www.enterprisedb.com