| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andreas Seltenreich <andreas(dot)seltenreich(at)credativ(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Excessive memory usage in multi-statement queries w/ partitioning |
| Date: | 2019-05-27 05:58:12 |
| Message-ID: | 3ed13306-ba63-f2e8-1eeb-63b0e4f377e6@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 multi-query strings could be handled by setting up a child
> context of MessageContext (after we've done the raw parsing there
> and determined that indeed there are multiple queries), running
> parse analysis and planning in that context, and resetting that
> context after each query.
Maybe like the attached? I'm not sure if we need to likewise be concerned
about exec_sql_string() being handed multi-query strings.
Thanks,
Amit
| Attachment | Content-Type | Size |
|---|---|---|
| parse-plan-memcxt.patch | text/plain | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex | 2019-05-27 06:01:34 | some questions about fast-path-lock |
| Previous Message | Kato, Sho | 2019-05-27 05:26:54 | RE: Why does not subquery pruning conditions inherit to parent query? |