Re: Excessive memory usage in multi-statement queries w/ partitioning

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Excessive memory usage in multi-statement queries w/ partitioning
Дата
Msg-id CAOBaU_ZAQiJpZ0YRoe+zUnJ0d1+Yd656oRtcSRQvx+WmNiWE7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Excessive memory usage in multi-statement queries w/ partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Excessive memory usage in multi-statement queries w/ partitioning  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
On Tue, May 28, 2019 at 6:57 AM Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> On 2019/05/27 21:56, Tom Lane wrote:
> > Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> >> On 2019/05/24 23:28, Tom Lane wrote:
> >>> So my thought, if we want to do something about this, is not "find
> >>> some things we can pfree at the end of planning" but "find a way
> >>> to use a separate context for each statement in the query string".
> >
> >> Maybe like the attached?  I'm not sure if we need to likewise be concerned
> >> about exec_sql_string() being handed multi-query strings.

the whole extension sql script is passed to execute_sql_string(), so I
think that it's a good thing to have similar workaround there.

About the patch:

 -        * Switch to appropriate context for constructing querytrees (again,
-        * these must outlive the execution context).
+        * Switch to appropriate context for constructing querytrees.
+        * Memory allocated during this construction is released before
+        * the generated plan is executed.

The comment should mention query and plan trees, everything else seems ok to me.



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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: Optimize partial TOAST decompression
Следующее
От: tushar
Дата:
Сообщение: Re: Minimal logical decoding on standbys