| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
| 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 16:32:45 |
| Message-ID: | 20240209163245.GB663211@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 09, 2024 at 01:19:49PM +0500, Andrey M. Borodin wrote:
> 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".
It might make sense to have a couple of built-in qsort implementations for
pointers to integers, pointers to unsigned integers, etc. However, a lot
of current use-cases require inspecting specific fields of structs, so
(assuming I understand your proposal correctly), we'd end up with many
qsort implementations. If that can be made simple and elegant and
demonstrates substantial improvements, then it might be worth considering,
but I'm somewhat skeptical that the current uses are performance-sensitive
enough to be worth the effort.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-02-09 16:36:57 | Re: [PATCH] allow pg_current_logfile() execution under pg_monitor role |
| Previous Message | Tom Lane | 2024-02-09 16:27:28 | Re: glibc qsort() vulnerability |