Re: memory leak in e94568ecc10 (pre-reading in external sort)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: memory leak in e94568ecc10 (pre-reading in external sort)
Дата
Msg-id cdc3ccb3-496f-7ad8-f4cd-e07215f83809@iki.fi
обсуждение исходный текст
Ответ на Re: memory leak in e94568ecc10 (pre-reading in external sort)  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 10/11/2016 12:56 AM, Peter Geoghegan wrote:
> Also, something about trace_sort here:
>
>> +#ifdef TRACE_SORT
>> +   if (trace_sort)
>> +       elog(LOG, "using " INT64_FORMAT " KB of memory for read buffers among %d input tapes",
>> +            (state->availMem) / 1024, numInputTapes);
>> +#endif
>> +
>> +   state->read_buffer_size = state->availMem / numInputTapes;
>> +   USEMEM(state, state->availMem);
>
> Maybe you should just make the trace_sort output talk about blocks at
> this point?

With # of blocks, you then have to mentally divide by 8 to get the 
actual memory used. I think kB is nicer in messages that are meant to be 
read by humans.

The bigger problem with this message is that it's not very accurate 
anymore. The actual amount of memory used is rounded down, and capped by 
MaxAllocSize*numInputTapes. And would it be better to print the per-tape 
buffer size, rather than the total?

- Heikki




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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: int2vector and btree indexes
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Quorum commit for multiple synchronous replication.