Re: Sort functions with specialized comparators
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-19T00:15:11Z
Lists: pgsql-hackers
Em sáb., 18 de mai. de 2024 às 15:52, Andrey M. Borodin < x4mmm@yandex-team.ru> escreveu: > Hi! > > In a thread about sorting comparators[0] Andres noted that we have > infrastructure to help compiler optimize sorting. PFA attached PoC > implementation. I've checked that it indeed works on the benchmark from > that thread. > > postgres=# CREATE TABLE arrays_to_sort AS > SELECT array_shuffle(a) arr > FROM > (SELECT ARRAY(SELECT generate_series(1, 1000000)) a), > generate_series(1, 10); > > postgres=# SELECT (sort(arr))[1] FROM arrays_to_sort; -- original > Time: 990.199 ms > postgres=# SELECT (sort(arr))[1] FROM arrays_to_sort; -- patched > Time: 696.156 ms > > The benefit seems to be on the order of magnitude with 30% speedup. > > There's plenty of sorting by TransactionId, BlockNumber, OffsetNumber, Oid > etc. But this sorting routines never show up in perf top or something like > that. > > Seems like in most cases we do not spend much time in sorting. But > specialization does not cost us much too, only some CPU cycles of a > compiler. I think we can further improve speedup by converting inline > comparator to value extractor: more compilers will see what is actually > going on. But I have no proofs for this reasoning. > > What do you think? > Makes sense. Regarding the patch. You could change the style to: +sort_int32_asc_cmp(const int32 *a, const int32 *b) +sort_int32_desc_cmp(const int32 *a, const int32 *b) We must use const in all parameters that can be const. best regards, Ranier Vilela
Commits
-
Specialize intarray sorting
- 53d3daa491be 18.0 landed
-
Replace insertion sort in contrib/intarray with qsort().
- 8d1f239003d0 9.5.0 cited