Re: Rethinking MemoryContext creation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Rethinking MemoryContext creation
Дата
Msg-id CA+Tgmoby7bcUuXfy76+XxcUQNtq0CjRG8M87gqxMF-8MyU7LbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rethinking MemoryContext creation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rethinking MemoryContext creation  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>     379 CurTransactionContext was never used
>      24 CurTransactionContext was used
>   66978 ExprContext was never used
>   17364 ExprContext was used
>   11139 SPI Exec was never used
>    2421 SPI Exec was used
>   38386 ginPlaceToPage temporary context was never used
>    3348 ginPlaceToPage temporary context was used

It strikes me that a way to optimize these cases even more would be to
postpone creating the context until it's actually needed.  That might
not always be a reasonable plan -- in particular, it occurs to me to
think that CurTransactionContext is probably so widely used that
changing anything about how it works would probably be really painful
-- but it might be possible in some cases.

Another idea I have is that perhaps we could arrange to reuse contexts
instead of destroying them and recreating them.  For example, when
asked to delete a context, we could instead push it on a linked list
of old contexts, or only if the list isn't too long already, and when
asked to create one, we could pop from the list.  Or we could keep
around an array of, say, 1024 contexts that are never freed and only
allocated dynamically when we run out.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rethinking MemoryContext creation
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Rethinking MemoryContext creation