Re: Sort functions with specialized comparators

From: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
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-04 18:15:27
Message-ID: 4DBEDEBB-D3C5-4516-A453-4F6F12F28DD9@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 4 Jan 2025, at 10:24, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>
> v6-0001:
>
> +static int
> +unique_cmp(const void *a, const void *b)
> +{
> + int32 aval = *((const int32 *) a);
> + int32 bval = *((const int32 *) b);
> +
> + return pg_cmp_s32(aval, bval);
> +}
>
> I'm not sure it makes sense to create a whole new function for this,
> when the same patch removed:
>
> -int
> -compASC(const void *a, const void *b)
> -{
> - return pg_cmp_s32(*(const int32 *) a, *(const int32 *) b);
> -}
>
> ...which in effect the exact same thing.
>
> Otherwise seems close to committable.

I thought about it, but decided to rename the routine.
Here's a version 7 with compASC().
And, just in case, if we already have ASC, why not keep DESC too instead of newly invented cmp function :) PFA v8.

Thanks!

Best regards, Andrey Borodin.

Attachment Content-Type Size
v7-0001-Use-specialized-sort-facilities.patch application/octet-stream 4.9 KB
v8-0001-Use-specialized-sort-facilities.patch application/octet-stream 4.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-04 19:35:47 Re: Using Expanded Objects other than Arrays from plpgsql
Previous Message Tomas Vondra 2025-01-04 16:58:36 Re: Parallel CREATE INDEX for GIN indexes