Re: function slower than the same code in an sql file

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

In response to

Browse pgsql-performance by date

  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?