From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Tuplesort merge pre-reading |
Date: | 2016-09-29 09:49:27 |
Message-ID: | 242c621b-62b6-f467-5c80-9c267efb2859@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/28/2016 07:20 PM, Peter Geoghegan wrote:
> On Wed, Sep 28, 2016 at 5:11 PM, Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Artur Zakirov | 2016-09-29 09:53:34 | Re: Bug in to_timestamp(). |
Previous Message | Kyotaro HORIGUCHI | 2016-09-29 08:58:13 | Re: An extra error for client disconnection on Windows |