Re: glibc qsort() vulnerability

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.

In response to

Responses

Browse pgsql-hackers by date

  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