X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 72B9C9DC842 for ; Fri, 20 Jan 2006 14:51:24 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 31580-05 for ; Fri, 20 Jan 2006 14:51:22 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from pop.xnet.hr (dns1.xnet.hr [82.193.192.5]) by postgresql.org (Postfix) with ESMTP id BD4D69DCB74 for ; Fri, 20 Jan 2006 14:51:18 -0400 (AST) Received: (qmail 26701 invoked from network); 20 Jan 2006 18:51:45 -0000 Received: by simscan 1.1.0 ppid: 26692, pid: 26694, t: 0.5947s scanners: attach: 1.1.0 clamav: 0.87/m:34/d:1131 spam: 3.1.0 Received: from unknown (HELO ?83.139.74.33?) (83.139.74.33) by pop.xnet.hr with SMTP; 20 Jan 2006 18:51:44 -0000 Message-ID: <43D130EF.3010205@zg.htnet.hr> Date: Fri, 20 Jan 2006 19:50:23 +0100 From: Rikard Pavelic User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: [PERFORMANCE] Stored Procedures Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.479 required=5 tests=[DNS_FROM_RFC_ABUSE=0.479] X-Spam-Score: 0.479 X-Spam-Level: X-Archive-Number: 200601/351 X-Sequence-Number: 16829 >>Hi, >> >> Will simple queries such as "SELECT * FROM blah_table WHERE tag='x'; work any >> faster by putting them into a stored procedure? > >IMHO no, why do you think so? You can use PREPARE instead, if you have many >selects like this. I tought that creating stored procedures in database means storing it's execution plan (well, actually storing it like a compiled object). Well, that's what I've learned couple a years ago in colledge ;) What are the advantages of parsing SP functions every time it's called? My position is that preparing stored procedures for execution solves more problems, that it creates. And the most important one to be optimizing access to queries from multiple connections (which is one of the most important reasons for using stored procedures in the first place). Best regards, Rikard