Re: Sort functions with specialized comparators
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: David Rowley <dgrowleyml@gmail.com>, Антуан Виолин <violin.antuan@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-14T08:58:40Z
Lists: pgsql-hackers
Attachments
- v10-0001-Use-specialized-sort-facilities.patch (text/x-patch) patch v10-0001
I wrote: > On Tue, Jan 7, 2025 at 12:59 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > And one more case. > > BTW for pre-sorted desc arrays desc sorting is slower: > > Right, that's because the sort template special-cases pre-sorted input, and that only works for descending input if the comparator is wired for descending output. I'm still not in favor of having two separate specializations because that's kind of a brute force approach, and even if that's okay this is a strange place to set that precedent [*]. The principled way to avoid this regression is to add a one-time check for descending input in the template, which would be more widely beneficial. I suspect (and I think the archives show others wondering the same) we could make the ascending pre-check a one-time operation as well, but I'd need to test. That's not as clear-cut as I thought. To avoid regressions, I've gone back to an earlier idea to pass the direction to the comparator, but this time keep it simple by using the same comparator for sort and unique, similar to v9. -- John Naylor Amazon Web Services
Commits
-
Specialize intarray sorting
- 53d3daa491be 18.0 landed
-
Replace insertion sort in contrib/intarray with qsort().
- 8d1f239003d0 9.5.0 cited