回复: An implementation of multi-key sort
| От | Wang Yao |
|---|---|
| Тема | 回复: An implementation of multi-key sort |
| Дата | |
| Msg-id | PH7P220MB1533510BCBAC3B515E5C1403D9F42@PH7P220MB1533.NAMP220.PROD.OUTLOOK.COM обсуждение исходный текст |
| Ответ на | Re: An implementation of multi-key sort (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: 回复: An implementation of multi-key sort
|
| Список | pgsql-hackers |
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
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
发送时间: 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)
> 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)
Вложения
В списке pgsql-hackers по дате отправления: