Re: Limiting memory allocation

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Limiting memory allocation
Дата
Msg-id Yo1zkfC1oKO5cF3m@momjian.us
обсуждение исходный текст
Ответ на Re: Limiting memory allocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Limiting memory allocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, May 24, 2022 at 07:40:45PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > If the plan output is independent of work_mem,
> 
> ... it isn't ...

Good.

> > I always wondered why we
> > didn't just determine the number of simultaneous memory requests in the
> > plan and just allocate accordingly, e.g. if there are four simultaneous
> > memory requests in the plan, each gets work_mem/4.
> 
> (1) There are not a predetermined number of allocations.  For example,
> if we do a given join as nestloop+inner index scan, that doesn't require
> any large amount of memory; but if we do it as merge or hash join then
> it will consume memory.

Uh, we know from the plan whether we are doing a nestloop+inner or merge
or hash join, right?  I was suggesting we look at the plan before
execution and set the proper percentage of work_mem for each node.

> (2) They may not all need the same amount of memory, eg joins might
> be working on different amounts of data.

True. but we could cap it like we do now for work_mem, but as a
percentage of a GUC work_mem total.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: allow building trusted languages without the untrusted versions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: PG15 beta1 sort performance regression due to Generation context change