No obvious perf regression is expected because PG will follow original qsort code path when mksort is disabled. For the case, the only extra cost is the check in tuplesort_sort_memtuples() to enter mksort code path.
It's also proved by the experiment today: Mksort disabled: 2949.287 ms 2955.258 ms 2947.262 ms No mksort code: 2947.094 ms 2946.419 ms 2953.215 ms Almost the same. I also updated code with small enhancements. Please see the latest code as attachment. Thanks, Yao Wang ________________________________ 发件人: Heikki Linnakangas <hlinn...@iki.fi> 发送时间: 2024年5月22日 23:29 收件人: Wang Yao <yaowa...@outlook.com>; PostgreSQL Hackers <pgsql-hack...@postgresql.org> 抄送: inte...@outlook.com <inte...@outlook.com> 主题: Re: An implementation of multi-key sort On 22/05/2024 15:48, Wang Yao wrote: > Comparing to classic quick sort, it can get significant performance > improvement once multiple keys are available. A rough test shows it got > ~129% improvement than qsort for ORDER BY on 6 keys, and ~52% for CREATE > INDEX on the same data set. (See more details in section "Performance > Test") Impressive. Did you test the performance of the cases where MK-sort doesn't help, to check if there is a performance regression? -- Heikki Linnakangas Neon (https://neon.tech)
v2-Implement-multi-key-sort.patch
Description: v2-Implement-multi-key-sort.patch
