Re: [HACKERS] Small improvement to compactify_tuples

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: [HACKERS] Small improvement to compactify_tuples
Дата
Msg-id CAGTBQpaq4HAtMO-WPaB5dbrLBXcm69+eZC2C51A1oy4rfO+PMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Small improvement to compactify_tuples  (Юрий Соколов <funny.falcon@gmail.com>)
Ответы Re: [HACKERS] Small improvement to compactify_tuples
Список pgsql-hackers
On Sat, Nov 4, 2017 at 8:07 PM, Юрий Соколов <funny.falcon@gmail.com> wrote:
> 2017-11-03 5:46 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>:
>>
>> Sokolov Yura <funny.falcon@postgrespro.ru> writes:
>> > [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>>
>> I went to check the shellsort algorithm against Wikipedia's entry,
>> and found that this appears to be an incorrect implementation of
>> shellsort: where pg_shell_sort_pass has
>>
>>                 for (_i = off; _i < _n; _i += off) \
>>
>> it seems to me that we need to have
>>
>>                 for (_i = off; _i < _n; _i += 1) \
>>
>> or maybe just _i++.
>
>
> Shame on me :-(
> I've wrote shell sort several times, so I forgot to recheck myself once
> again.
> And looks like best gap sequence from wikipedia is really best
> ( {301, 132, 57, 23, 10 , 4} in my notation),
>
>
> 2017-11-03 17:37 GMT+03:00 Claudio Freire <klaussfreire@gmail.com>:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>>
>> I did manage to reproduce the original test and got a consistent
>> improvement.
>
> I've rechecked my self using my benchmark.
> Without memmove, compactify_tuples comsumes:
> - with qsort 11.66% cpu (pg_qsort + med3 + swapfunc + itemoffcompare +
> compactify_tuples = 5.97 + 0.51 + 2.87 + 1.88 + 0.44)
> - with just insertion sort 6.65% cpu (sort is inlined, itemoffcompare also
> inlined, so whole is compactify_tuples)
> - with just shell sort 5,98% cpu (sort is inlined again)
> - with bucket sort 1,76% cpu (sort_itemIds + compactify_tuples = 1.30 +
> 0.46)

Is that just insertion sort without bucket sort?

Because I think shell sort has little impact in your original patch
because it's rarely exercised. With bucket sort, most buckets are very
small, too small for shell sort to do any useful work.

That's why I'm inclined to agree with Tom in that we could safely
simplify it out, remove it, without much impact.

Maybe leave a fallback to qsort if some corner case produces big buckets?


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: [HACKERS] Re: [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xminupdates.
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: [HACKERS] Custom compression methods