Postgres Pro
Downloads
Home   >   mailing lists

回复: An implementation of multi-key sort - Mailing list pgsql-hackers

From Wang Yao
Subject 回复: An implementation of multi-key sort
Date
Msg-id PH7P220MB1533510BCBAC3B515E5C1403D9F42@PH7P220MB1533.NAMP220.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: An implementation of multi-key sort  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: 回复: An implementation of multi-key sort
List pgsql-hackers
Tree view
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@iki.fi>
发送时间: 2024年5月22日 23:29
收件人: Wang Yao <yaowangm@outlook.com>; PostgreSQL Hackers <pgsql-hackers@postgresql.org>
抄送: interma@outlook.com <interma@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)

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Pgoutput not capturing the generated columns
Next
From: Heikki Linnakangas
Date:
Subject: Re: 回复: An implementation of multi-key sort