Re: 9.5: Better memory accounting, towards memory-bounded HashAgg

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Дата
Msg-id CAM3SWZT5Qj2m-Rf8UOgvmQVw_2HoN1V5ZpFAoO_rHskaBHoUGA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: 9.5: Better memory accounting, towards memory-bounded HashAgg  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> I can also just move isReset there, and keep mem_allocated as a uint64.
> That way, if I find later that I want to track the aggregated value for
> the child contexts as well, I can split it into two uint32s. I'll hold
> off any any such optimizations until I see some numbers from HashAgg
> though.

I took a quick look at memory-accounting-v8.patch.

Is there some reason why mem_allocated is a uint64? All other things
being equal, I'd follow the example of tuplesort.c's
MemoryContextAllocHuge() API, which (following bugfix commit
79e0f87a1) uses int64 variables to track available memory and so on.

-- 
Peter Geoghegan



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Buildfarm not happy with test module move
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum