Re: tuplesort_gettuple_common() and *should_free argument - Mailing list pgsql-hackers

From David Steele
Subject Re: tuplesort_gettuple_common() and *should_free argument
Date
Msg-id d45241c3-4ff0-f2a6-0a84-0314da72e704@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi Anastasia,

On 3/13/17 9:14 PM, Peter Geoghegan wrote:
> On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Please.  You might want to hit the existing ones with a separate patch,
>>> but it doesn't much matter; I'd be just as happy with a patch that did
>>> both things.
>>
>> Got it.
> 
> Attached is a patch that does both things at once. The internal
> function tuplesort_gettuple_common() still mentions repeated fetches,
> since that context matters to its internal callers. The various
> external-facing functions have a simpler, stricter contract, as
> discussed.
> 
> I didn't end up adding a line like "copy=FALSE is recommended only
> when the next tuplesort manipulation will be another
> tuplesort_gettupleslot fetch into the same slot", which you suggested.
> When the tuplesort state machine is in any state following
> "performing" a sort, there are very few remaining sane manipulations.
> Just things like skipping or seeking around for tuples, and actually
> ending the tuplesort and releasing resources.

You are signed up to review this patch.  Do you know when you'll have a
chance to do that?

Thanks,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Partition-wise join for join between (declaratively)partitioned tables
Next
From: Robert Haas
Date:
Subject: Re: Parallel Append implementation