X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 1E75BD1C4C9 for ; Wed, 30 Jul 2003 03:54:10 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 26783-04 for ; Wed, 30 Jul 2003 00:53:08 -0300 (ADT) Received: from joeconway.com (66-146-172-86.skyriver.net [66.146.172.86]) by svr1.postgresql.org (Postfix) with ESMTP id 115BBD1C4B7 for ; Wed, 30 Jul 2003 00:54:08 -0300 (ADT) Received: from [192.168.5.3] (account jconway HELO joeconway.com) by joeconway.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 17469; Tue, 29 Jul 2003 20:16:59 -0700 Message-ID: <3F2740A8.7020900@joeconway.com> Date: Tue, 29 Jul 2003 20:51:04 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Bronnimann Cc: Rod Taylor , pgsql-sql@postgresql.org Subject: Re: function returning setof performance question References: <20030730020859.GA1795@spiff.astoria.bogus> <1059532098.54325.23.camel@jester> <20030730025727.GA2094@spiff.astoria.bogus> In-Reply-To: <20030730025727.GA2094@spiff.astoria.bogus> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200307/443 X-Sequence-Number: 14557 Mark Bronnimann wrote: > I was hoping to eliminate the parse call on the view because I was doing > the where clause on the view instead of putting the where in the view. > In all, I was hoping to keep a single view called from multiple functions > with different where clauses. Yep... I shoulda known better... > It sounds like you're using a sql function, not a plpgsql function (although I don't think you said either way). If you write the function in plpgsql it will get parsed and cached on the first call in a particular backend session, which *might* give you improved performance on subsequent calls, if there are any; are you using persistent connections? Alternatively, it might work to use a prepared query. Joe