Re: The case for removing replacement selection sort

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The case for removing replacement selection sort
Date: 2017-08-31 00:56:34
Message-ID: CAH2-Wzk+AUWRh7COi66GY5wA16z3Qs12ur-Rhj7FxOQBfJhCAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 30, 2017 at 5:38 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-08-31 01:42:04 Re: pgbench: Skipping the creating primary keys after initialization
Previous Message Robert Haas 2017-08-31 00:38:52 Re: The case for removing replacement selection sort