Re: Add GUC to tune glibc's malloc implementation.

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Add GUC to tune glibc's malloc implementation.
Дата
Msg-id e1ce9d7e-745d-5ae9-208a-3e57065a11ec@eisentraut.org
обсуждение исходный текст
Ответ на Add GUC to tune glibc's malloc implementation.  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Ответы Re: Add GUC to tune glibc's malloc implementation.  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Список pgsql-hackers
On 22.06.23 15:35, Ronan Dunklau wrote:
> The thing is, by default, those parameters are adjusted dynamically by the
> glibc itself. It starts with quite small thresholds, and raises them when the
> program frees some memory, up to a certain limit. This patch proposes a new
> GUC allowing the user to adjust those settings according to their workload.
> 
> This can cause problems. Let's take for example a table with 10k rows, and 32
> columns (as defined by a bench script David Rowley shared last year when
> discussing the GenerationContext for tuplesort), and execute the following
> query, with 32MB of work_mem:

I don't follow what you are trying to achieve with this.  The examples 
you show appear to work sensibly in my mind.  Using this setting, you 
can save some of the adjustments that glibc does after the first query. 
But that seems only useful if your session only does one query.  Is that 
what you are doing?




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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH