Re: Tuplesort merge pre-reading

On 09/28/2016 07:20 PM, Peter Geoghegan wrote:
> On Wed, Sep 28, 2016 at 5:11 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> This is why I never pursued batch memory for non-final merges. Isn't
>> that what you're doing here? You're pretty much always setting
>> "state->batchUsed = true".
>
> Wait. I guess you feel you have to, since it wouldn't be okay to use
> almost no memory per tape on non-final merges.
>
> You're able to throw out so much code here in large part because you
> give almost all memory over to logtape.c (e.g., you don't manage each
> tape's share of "slots" anymore -- better to give everything to
> logtape.c). So, with your patch, you would actually only have one
> caller tuple in memory at once per tape for a merge that doesn't use
> batch memory (if you made it so that a merge *could* avoid the use of
> batch memory, as I suggest).

Correct.

> In summary, under your scheme, the "batchUsed" variable contains a
> tautological value, since you cannot sensibly not use batch memory.
> (This is even true with !state->tuples callers).

I suppose.

> Do I have that right? If so, this seems rather awkward. Hmm.

How is it awkward?

- Heikki