回复: An implementation of multi-key sort

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 <hlinnaka(at)iki(dot)fi>
发送时间: 2024年5月22日 23:29
收件人: Wang Yao <yaowangm(at)outlook(dot)com>; PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
抄送: interma(at)outlook(dot)com <interma(at)outlook(dot)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)