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

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
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

In response to

Responses

Browse pgsql-hackers by date

  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?