Re: Tuplesort merge pre-reading

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Tuplesort merge pre-reading
Дата
Msg-id 242c621b-62b6-f467-5c80-9c267efb2859@iki.fi
обсуждение исходный текст
Ответ на Re: Tuplesort merge pre-reading  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Tuplesort merge pre-reading  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: An extra error for client disconnection on Windows
Следующее
От: Artur Zakirov
Дата:
Сообщение: Re: Bug in to_timestamp().