Re: Sort Refinement - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Sort Refinement
Date
Msg-id 87fxult467.fsf@oxford.xeocode.com
Whole thread Raw
In response to Sort Refinement  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Sort Refinement  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> If we assume we use heap sort, then if we *know* that the data is
> presorted on (a) then we should be able to emit tuples directly that the
> value of (a) changes and keep emitting them until the heap is empty,
> since they will exit the heap in (a,b) order.

Actually, I would think the way to do this would be to do a quicksort if you
find you've accumulated all the records in a subgroup in memory. One easy way
to do it would be to have nodeSort build a new tuplesort for each subgroup if
it has a level break key parameter set (memories of RPG III are coming
bubbling to the surface).

What I wonder is what the optimal thing to do really is if a level doesn't fit
in memory. Is it best to do a disk sort just of that level and then return to
accumulating levels one by one in memory? Or is it best to fail over to a
single disk sort of all the remaining tuples?

Also, I wonder how expensive checking the level break key on every tuple will
be. I don't think it invalidates the approach but it has to be taken into
account.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: [Fwd: Re: [PATCHES] 64-bit CommandIds]
Next
From: Tom Lane
Date:
Subject: Re: gcc 4.3 breaks ContribCheck in 8.2 and older.