回复: 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

发件人: 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)

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Pgoutput not capturing the generated columns
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: 回复: An implementation of multi-key sort