Re: [HACKERS] Automatically setting work_mem

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] Automatically setting work_mem
Дата
Msg-id 1145703080.3112.195.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: [HACKERS] Automatically setting work_mem  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] Automatically setting work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
On Fri, 2006-04-21 at 23:07 -0400, Bruce Momjian wrote:
> Where are we on this patch?

Well the patches work and have been performance tested, with results
posted. Again, the title of this thread doesn't precisely describe the
patch any longer.

The question is do people believe there is benefit in reducing the
amount of memory for the final sort phase, and if so, to what level?

I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the brk
point can't be changed. For large queries with multiple sorts the memory
can be reused immediately.

The patch does sound somewhat obscure and a corner case, I grant you,
but the more memory you give a sort the smaller number of runs you are
likely to have. So the situation of having enough memory to, say, merge
500 runs at the same time as having less than 10 runs is actually IMHO
the common case.

Patch now is: "Reducing memory usage in sort final merge phase."

[I've also completed Cascade Merge sort ready for unit testing, but will
not be completing that for a few weeks yet]

--
  Simon Riggs
  EnterpriseDB          http://www.enterprisedb.com/


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Automatically setting work_mem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Automatically setting work_mem