Re: Memory Accounting v11

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Memory Accounting v11
Дата
Msg-id CANP8+jL_y87LQ2oqGrdNn72UCyJmSqjNb1oBbRAk0yzxEAWf0g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory Accounting v11  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Memory Accounting v11  (CK Tan <cktan@vitessedata.com>)
Список pgsql-hackers
On 14 June 2015 at 23:51, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
 
The current state, where HashAgg just blows up the memory, is just not
reasonable, and we need to track the memory to fix that problem.

Meh. HashAgg could track its memory usage without loading the entire
system with a penalty.

+1 to a solution like that, although I don't think that's doable without digging the info from memory contexts somehow.

Jeff is right, we desperately need a solution and this is the place to start.

Tom's concern remains valid: we must not load the entire system with a penalty.


The only questions I have are:

* If the memory allocations adapt to the usage pattern, then we expect to see few memory chunk allocations. Why are we expecting "the entire system" to experience a penalty?

* If we do not manage our resources, how are we certain this does not induce a penalty? Not tracking memory could be worse than tracking it.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: raw output from copy
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx