From: | CS DBA <cs_dba(at)consistentstate(dot)com> |
---|---|
To: | |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: function slower than the same code in an sql file |
Date: | 2011-11-03 22:42:13 |
Message-ID: | 4EB318C5.20504@consistentstate.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 11/03/2011 09:40 AM, Robert Haas wrote:
> On Thu, Nov 3, 2011 at 11:31 AM, Rodrigo Gonzalez
> <rjgonzale(at)estrads(dot)com(dot)ar> wrote:
>> El 03/11/11 11:42, Robert Haas escribió:
>>
>> On Fri, Oct 28, 2011 at 9:39 AM, CS DBA<cs_dba(at)consistentstate(dot)com> wrote:
>>
>> No parameters, one of them looks like this:
>>
>> [ code snippet ]
>>
>> It's hard to believe this is the real code, because SELECT without
>> INTO will bomb out inside a PL/pgsql function, won't it?
>>
>> But he's using CREATE TABLE xyz_view_m AS
>>
>> So it seems correct to me
> Oh, right, I missed that.
>
> That seems pretty mysterious then. But is it possible the function is
> getting called more times than it should? I notice that it's set up
> as a trigger; is it FOR EACH ROW when it should be a statement-level
> trigger or something like that? Maybe run EXPLAIN ANALYZE on the
> query that's invoking the trigger to get some more detail on what's
> going on?
I'll give it a shot ...
--
---------------------------------------------
Kevin Kempter - Constent State
A PostgreSQL Professional Services Company
www.consistentstate.com
---------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-03 23:45:46 | Re: Blocking excessively in FOR UPDATE |
Previous Message | Tom Lane | 2011-11-03 20:35:16 | Re: Predicates not getting pushed into SQL function? |