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 по дате отправления: