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

From Peter Geoghegan
Subject Re: Using quicksort for every external sort run
Date
Msg-id CAM3SWZQAbqTF9tTFa+vr=W8cydJh7twxkViSpxuiA6e0+AagUw@mail.gmail.com
Whole thread Raw
In response to Re: Using quicksort for every external sort run  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Wed, Dec 23, 2015 at 1:03 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> If we do think it is important to almost never cause regressions at
> the default maintenance_work_mem (I am agnostic on the importance of
> that), then I think we have more work to do here.  I just don't know
> what that work is.

My next revision will use grow_memtuples() in advance of the final
on-the-fly merge step, in a way that considers that we won't be losing
out to palloc() overhead (so it'll mostly be the memory patch that is
revised). This can make a large difference to the number of slots
(memtuples) available. I think I measured a 6% or 7% additional
improvement for a case with a fairly small number of runs to merge. It
might help significantly more when there are more runs to merge.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Robert Haas
Date:
Subject: Re: Using quicksort for every external sort run