On Tue, Sep 13, 2016 at 5:32 PM, Alexander Korotkov
<aekorotkov@gmail.com> wrote:
> On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>
>> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov
>> <aekorotkov@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
