From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance bug in DO blocks |
Date: | 2011-03-27 15:15:07 |
Message-ID: | 12828.1301238907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 18, 2011 at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I just noticed that if you execute the same DO command over and over
>> within a session, it gets slower and slower. And if you keep it up
>> you'll notice the backend's RAM consumption bloating too. The cause
>> appears to be that we leak the cached plans created for any SQL
>> statements or expressions within the DO command --- the next iteration
>> won't reuse those, but rather create its own set. Probably ought to
>> look into releasing those when the DO block is over.
> Should we try to do something about this?
> I don't really understand what's going on here. I thought maybe the
> problem was that the inline handler was getting called with
> TopMemoryContext active, but it's not.
No, the problem is that (a) the internal function representation
produced by plpgsql_compile_inline is never recycled, and (b) the
cached plans held by plancache.c are never released. When dealing
with an ordinary function it's reasonable to hang onto those things
on the expectation that the function will be called again in the
session. But for an inline code block it's leakage, plain and simple.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2011-03-27 16:50:10 | Re: Needs Suggestion |
Previous Message | 3dmashup | 2011-03-27 14:57:16 | Re: Needs Suggestion |