Re: Using quicksort for every external sort run - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Using quicksort for every external sort run
Date
Msg-id CANP8+jLuCY7fy+WkYdFtFKFriQGzAkzsKbCqCmB1LJ0H7WEoRg@mail.gmail.com
Whole thread Raw
In response to Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Using quicksort for every external sort run  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 20 November 2015 at 22:58, Peter Geoghegan <pg@heroku.com> wrote:
 
The numbers speak for themselves here. I just want to be clear about
the disadvantages of what I propose, even if it's well worth it
overall in most (all?) cases.

My feeling is that numbers rarely speak for themselves, without LSD. (Which numbers?)

How are we doing here? Keen to see this work get committed, so we can move onto parallel sort. What's the summary?

How about we commit it with a sort_algorithm = 'foo' parameter so we can compare things before release of 9.6?

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Michael Paquier
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.