Re: Sort functions with specialized comparators

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

In response to

Responses

Browse pgsql-hackers by date

  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+