From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Антуан Виолин <violin(dot)antuan(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sort functions with specialized comparators |
Date: | 2025-01-14 08:58:40 |
Message-ID: | CANWCAZZ44FLaWKNEMM1HY6O9JdN399R4S8UFfrVZKt+4JaQChQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> On Tue, Jan 7, 2025 at 12:59 PM Andrey M. Borodin <x4mmm(at)yandex-team(dot)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
Attachment | Content-Type | Size |
---|---|---|
v10-0001-Use-specialized-sort-facilities.patch | text/x-patch | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-01-14 09:01:57 | Re: Reduce TupleHashEntryData struct size by half |
Previous Message | Alvaro Herrera | 2025-01-14 08:51:45 | Re: Psql meta-command conninfo+ |