| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2015-11-24 23:32:16 |
| Message-ID: | CANP8+jLuCY7fy+WkYdFtFKFriQGzAkzsKbCqCmB1LJ0H7WEoRg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20 November 2015 at 22:58, Peter Geoghegan <pg(at)heroku(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2015-11-25 00:08:33 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
| Previous Message | Masahiko Sawada | 2015-11-24 23:13:31 | Re: Freeze avoidance of very large table. |