Re: OOM on EXPLAIN with lots of nodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Alexey Bashtanov <bashtanov(at)imap(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: OOM on EXPLAIN with lots of nodes
Date: 2015-01-13 15:19:40
Message-ID: 11105.1421162380@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 01/13/2015 02:08 PM, Alexey Bashtanov wrote:
>> By varying the parameters and reading source code I determined that
>> memory usage linearly depends on (plan nodes count)*(overall columns
>> count), thus it quadratically depends on number of tables unionized.
>>
>> To remove this excessive memory usage I propose
>> to run deparse_context_for_planstate+deparse_expression in a separate
>> memory context and free it after a plan node is generated.

> Hmm, something like the attached? Seems reasonable...

This looks pretty unsafe to me: it assumes, without much justification,
that there is no memory allocated during show_expression() that will be
needed later.

I suspect the O(N^2) consumption comes directly from some workspace
allocated for variable deparsing in ruleutils.c. A safer fix would
be to do retail pfrees on that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-01-13 15:56:48 Re: [HACKERS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
Previous Message Tom Lane 2015-01-13 15:10:22 Re: Safe memory allocation functions