From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bugfix patch for json_array_elements |
Date: | 2014-02-03 14:05:19 |
Message-ID: | 52EFA21F.60707@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/02/2014 08:54 PM, Craig Ringer wrote:
> On 02/03/2014 09:09 AM, Craig Ringer wrote:
>
>> At a guess, we're looking at a case where a new child context is created
>> at every call, so every MemoryContextResetChildren call has to deal with
>> more child contexts.
> That would be "yes". After a short run, I see 32849 lines like:
>
> json_array_elements temporary cxt: 8192 total in 1 blocks; 8160 free (0
> chunks); 32 used
>
> under the context:
>
> PortalMemory: 8192 total in 1 blocks
> PortalHeapMemory: 7168 total in 3 blocks
> ExecutorState: 65600 total in 4 blocks
> ExprContext: 8192 total in 1 blocks
> json_array_elements temporary cxt: 8192 total in 1 blocks;
> 8160 free (0 chunks); 32 used
>
>
> The attached patch deletes the context after use, bringing performance
> back into line. It should be backpatched to 9.3.
[...]
> + MemoryContextDelete(state->tmp_cxt);
> + state->tmp_cxt = NULL;
> +
> PG_RETURN_NULL();
Hmm. I guess I was assuming that the tmp_cxt would be cleaned up at the
end of the function since it's a child of the CurrentMemoryContext. But
if I got that wrong I'm happy to fix it. I don't see the point in
setting state->tmp_cxt to NULL since it's about to go out of scope anyway.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2014-02-03 14:06:08 | Re: [review] PostgreSQL Service on Windows does not start if data directory given is relative path |
Previous Message | Tom Lane | 2014-02-03 14:05:04 | Re: narwhal and PGDLLIMPORT |