Re: [HACKERS] The case for removing replacement selection sort

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: [HACKERS] The case for removing replacement selection sort
Дата
Msg-id CAH2-Wzk+AUWRh7COi66GY5wA16z3Qs12ur-Rhj7FxOQBfJhCAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] The case for removing replacement selection sort  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] The case for removing replacement selection sort  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Aug 30, 2017 at 5:38 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Wow.  Just to be clear, I am looking for the BEST case for replacement
> selection, not the worst case.  But I would have expected that case to
> be a win for replacement selection, and it clearly isn't.  I can
> reproduce your results here.

But I *was* trying to get a best case. That's why it isn't even worse.
That's what the docs say the best case is, after all.

This is the kind of thing that replacement selection actually did do
better with on 9.6. I clearly remember Tomas Vondra doing lots of
benchmarking, showing some benefit with RS with a work_mem of 8MB or
less. As I said in my introduction on this thread, we weren't wrong to
add replacement_sort_tuples to 9.6, given where things were with
merging at the time. But, it does very much appear to create less than
zero benefit these days. The picture changed.

-- 
Peter Geoghegan



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] The case for removing replacement selection sort
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization