Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 22EEAB5DC44 for ; Fri, 28 Oct 2011 10:39:53 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 22151-03 for ; Fri, 28 Oct 2011 13:39:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) by mail.postgresql.org (Postfix) with ESMTP id 2290DB5DC42 for ; Fri, 28 Oct 2011 10:39:45 -0300 (ADT) Received: by qyk27 with SMTP id 27so4513430qyk.19 for ; Fri, 28 Oct 2011 06:39:46 -0700 (PDT) Received: by 10.68.38.100 with SMTP id f4mr4324314pbk.62.1319809184867; Fri, 28 Oct 2011 06:39:44 -0700 (PDT) Received: from issac.consistentstate.com (c-67-165-192-103.hsd1.co.comcast.net. [67.165.192.103]) by mx.google.com with ESMTPS id y6sm12618408pbi.5.2011.10.28.06.39.41 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 06:39:42 -0700 (PDT) Message-ID: <4EAAB09C.9060202@consistentstate.com> Date: Fri, 28 Oct 2011 07:39:40 -0600 From: CS DBA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org Subject: Re: function slower than the same code in an sql file References: <4EAA3597.3020202@consistentstate.com> <14399.1319778608@sss.pgh.pa.us> In-Reply-To: <14399.1319778608@sss.pgh.pa.us> Content-Type: multipart/alternative; boundary="------------000708070307000508040704" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201110/252 X-Sequence-Number: 45474 This is a multi-part message in MIME format. --------------000708070307000508040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/27/2011 11:10 PM, Tom Lane wrote: > CS DBA writes: >> I have code that drops a table, re-create's it (based on a long set of >> joins) and then re-creates the indexes. >> It runs via psql in about 10 seconds. I took the code and simply >> wrapped it into a plpgsql function and the function version takes almost >> 60 seconds to run. >> I always thought that functions should run faster than psql... am I wrong? > Did you really just put the identical queries into a function, or did > you parameterize them with values passed to the function? > > Parameterized queries are often slower due to the planner not knowing > the specific constant values that are used in the actual calls. There's > some work done for 9.2 to improve that, but in existing releases you > typically have to construct dynamic queries and EXECUTE them if you run > into this problem. > > regards, tom lane No parameters, one of them looks like this: CREATE or REPLACE FUNCTION refresh_xyz_view_m() RETURNS TRIGGER AS $$ BEGIN DROP TABLE xyz_view_m ; CREATE TABLE xyz_view_m AS SELECT pp.id, pp.name, pp.description, pp.tariff_url, ppe.account_id, pp.active, ppe.time_zone FROM tab1 pp, enrollment ppe WHERE ((pp.id = ppe.pp_id) AND pp.active); create index xyz_m_id_idx on xyx_view_m(id); analyze xyz_view_m; RETURN NULL; END $$ LANGUAGE plpgsql; -- --------------------------------------------- Kevin Kempter - Constent State A PostgreSQL Professional Services Company www.consistentstate.com --------------------------------------------- --------------000708070307000508040704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/27/2011 11:10 PM, Tom Lane wrote:
CS DBA <cs_dba@consistentstate.com> writes:
I have code that drops a table, re-create's it (based on a long set of 
joins) and then re-creates the indexes.

      
It runs via psql in about 10 seconds.  I took the code and simply 
wrapped it into a plpgsql function and the function version takes almost 
60 seconds to run.

      
I always thought that functions should run faster than psql... am I wrong?
Did you really just put the identical queries into a function, or did
you parameterize them with values passed to the function?

Parameterized queries are often slower due to the planner not knowing
the specific constant values that are used in the actual calls.  There's
some work done for 9.2 to improve that, but in existing releases you
typically have to construct dynamic queries and EXECUTE them if you run
into this problem.

			regards, tom lane


No parameters,  one of them looks like this:


CREATE or REPLACE FUNCTION refresh_xyz_view_m() RETURNS TRIGGER  AS $$                                                                             
BEGIN                                                                          
                                                                               
DROP TABLE xyz_view_m ;                                            
CREATE TABLE xyz_view_m AS                                         
SELECT                                                                         
        pp.id, pp.name, pp.description, pp.tariff_url, ppe.account_id, pp.active, ppe.time_zone                                                                
FROM                                                                           
        tab1 pp, enrollment ppe                     
WHERE                                                                          
        ((pp.id = ppe.pp_id) AND pp.active);                      
                                                                               
create index xyz_m_id_idx on xyx_view_m(id);          
                                                               
                                                                               
analyze xyz_view_m;                                                
                                                                               
RETURN NULL;                                                                   
END                                                                            
$$                                                                             
LANGUAGE plpgsql;

-- 
---------------------------------------------
Kevin Kempter       -       Constent State 
A PostgreSQL Professional Services Company
          www.consistentstate.com
---------------------------------------------
--------------000708070307000508040704--