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 3C33B9DC804 for ; Sat, 21 Jan 2006 17:06:58 -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 51628-03 for ; Sat, 21 Jan 2006 17:06:57 -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 6193E9DC85A for ; Sat, 21 Jan 2006 17:06:52 -0400 (AST) Received: (qmail 23354 invoked from network); 21 Jan 2006 21:07:24 -0000 Received: by simscan 1.1.0 ppid: 23342, pid: 23348, t: 0.5873s 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; 21 Jan 2006 21:07:24 -0000 Message-ID: <43D2A245.6040804@zg.htnet.hr> Date: Sat, 21 Jan 2006 22:06:13 +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 References: <43D130EF.3010205@zg.htnet.hr> <20060120191031.GO20182@pervasive.com> <43D13C2F.1030203@zg.htnet.hr> <20060120213455.GT20182@pervasive.com> In-Reply-To: <20060120213455.GT20182@pervasive.com> 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=[AWL=0.000, DNS_FROM_RFC_ABUSE=0.479] X-Spam-Score: 0.479 X-Spam-Level: X-Archive-Number: 200601/401 X-Sequence-Number: 16879 Jim C. Nasby wrote: > If you're dealing with something that's performance critical you're not > going to be constantly re-connecting anyway, so I don't see what the > issue is. > I didn't include mailing list in my second reply :( so here it is again. Someone may find this interesting... http://archives.postgresql.org/pgsql-general/2004-04/msg00084.php From Tom Lane: "EXECUTE means something different in plpgsql than it does in plain SQL, and you do not need PREPARE at all in plpgsql. plpgsql's automatic caching of plans gives you the effect of PREPARE on every statement without your having to ask for it."