On Tue, Sep 13, 2016 at 5:32 PM, Alexander Korotkov <aekorot...@gmail.com> wrote: > On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan <p...@heroku.com> wrote: >> >> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov >> <aekorot...@gmail.com> wrote: >> > Hmm... I'm not completely agree with that. In typical usage partial sort >> > should definitely use quicksort. However, fallback to other sort >> > methods is >> > very useful. Decision of partial sort usage is made by planner. But >> > planner makes mistakes. For example, our HashAggregate is purely >> > in-memory. >> > In the case of planner mistake it causes OOM. I met such situation in >> > production and not once. This is why I'd like partial sort to have >> > graceful >> > degradation for such cases. >> >> I think that this should be moved to the next CF, unless a committer >> wants to pick it up today. > > > Patch was rebased to current master.
Applies on HEAD at e8bdee27 and passes make-check, now I am seeing zero documentation so it is a bit hard to see what this patch is achieving without reading the thread. $ git diff master --check src/backend/optimizer/prep/prepunion.c:967: trailing whitespace. + cost_sort(&sorted_p, root, NIL, 0, src/backend/utils/sort/tuplesort.c:1244: trailing whitespace. + * tuplesort_updatemax + * Returns true if the plan node isautomatically materializes its output Typo here. Still, this has received to reviews, so moved to next CF. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
