Re: Excessive memory usage in multi-statement queries w/ partitioning - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Excessive memory usage in multi-statement queries w/ partitioning
Date
Msg-id CAOBaU_ZAQiJpZ0YRoe+zUnJ0d1+Yd656oRtcSRQvx+WmNiWE7Q@mail.gmail.com
Whole thread Raw
In response to Re: Excessive memory usage in multi-statement queries w/ partitioning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Excessive memory usage in multi-statement queries w/ partitioning
List 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 by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Optimize partial TOAST decompression
Next
From: tushar
Date:
Subject: Re: Minimal logical decoding on standbys