Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort" - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Date
Msg-id CA+TgmoZe_w-tMh+03y2b8zRrkRZSZ805bDpDF4c26viaeqe_eA@mail.gmail.com
Whole thread Raw
In response to Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
List pgsql-hackers
On Wed, Jul 29, 2015 at 9:05 PM, Peter Geoghegan <pg@heroku.com> wrote:
> The behavior of external sorts that do not require any merge step due
> to only having one run (what EXPLAIN ANALYZE output shows as an
> "external sort", and not a "merge sort") seems like an area that can
> be significantly improved upon. As noted in code comments, this
> optimization did not appear in The Art of Computer Programming, Volume
> III. It's not an unreasonable idea, but it doesn't work well on modern
> machines due to using heapsort, which is known to use the cache
> ineffectively. It also often implies significant additional I/O for
> little or no benefit. I suspect that all the reports we've heard of
> smaller work_mem sizes improving sort performance are actually down to
> this one-run optimization *hurting* performance.

Very interesting.  And great performance numbers.  Thanks for taking
the time to investigate this - really cool.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: security labels on databases are bad for dump & restore
Next
From: Robert Haas
Date:
Subject: Re: Reduce ProcArrayLock contention