From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mats Kindahl <mats(at)timescale(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: glibc qsort() vulnerability |
Date: | 2024-02-09 08:19:49 |
Message-ID: | B9DFF152-D31B-4E2D-A3DD-0AB92BFF71E4@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 8 Feb 2024, at 06:52, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> For the same compASC() test, I see an ~8.4% improvement with your int64
> code and a ~3.4% improvement with this:
If we care about branch prediction in comparison function, maybe we could produce sorting that inlines comparator, thus eliminating function call to comparator? We convert comparison logic to int, to extract comparison back then.
I bet “call" is more expensive than “if".
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-02-09 08:25:50 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Michael Paquier | 2024-02-09 08:13:44 | Re: Printing backtrace of postgres processes |