X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8E9DB9F944D for ; Tue, 16 May 2006 06:48:45 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 29493-07 for ; Tue, 16 May 2006 06:48:34 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 83D179FA278 for ; Tue, 16 May 2006 06:48:34 -0300 (ADT) Received: from bottom.rox.net (bottom.rox.net [213.214.0.43]) by svr4.postgresql.org (Postfix) with ESMTP id B29EE5B70B1 for ; Tue, 16 May 2006 09:48:33 +0000 (GMT) Received: from localhost ([127.0.0.1]) by bottom.rox.net with esmtp (Exim 4.62) (envelope-from ) id 1FfwAL-0004Me-AT; Tue, 16 May 2006 11:48:33 +0200 Received: from [87.217.68.213] (helo=mcknight.kawo2.rwth-aachen.de) by bottom.rox.net with esmtpa (Exim 4.62) (envelope-from ) id 1FfwAK-0004Ly-7w; Tue, 16 May 2006 11:48:32 +0200 Received: by mcknight.kawo2.rwth-aachen.de (Postfix, from userid 1000) id CA3174681A8; Tue, 16 May 2006 11:48:24 +0200 (CEST) Date: Tue, 16 May 2006 11:48:24 +0200 From: Joachim Wieland To: Tom Lane Cc: David Wheeler , pgsql-performance Subject: Re: IMMUTABLE? Message-ID: <20060516094824.GA2376@mcknight.de> References: <2D4C0FA5-DB75-45EA-91D2-7B4F6DD55083@kineticode.com> <5211.1147749711@sss.pgh.pa.us> <3F0CF576-8C6F-433C-9942-BB36F4E1A194@kineticode.com> <5894.1147753901@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5894.1147753901@sss.pgh.pa.us> X-Operating-System: Linux 2.6.13.4 on an i686 User-Agent: Mutt/1.5.9i X-Scanned-By: rockenstein AG X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/341 X-Sequence-Number: 19128 On Tue, May 16, 2006 at 12:31:41AM -0400, Tom Lane wrote: > It's true that the system *could* memoize (or in our more usual > parlance, cache function values) given the assumptions embodied in > IMMUTABLE. But we don't, and I don't see any statement in the docs > that promises that we do. For 99% of the functions that the planner > deals with, memoization would be seriously counterproductive because > the function evaluation cost is comparable to if not less than the > lookup cost in a memo table. (int4pl is a good case in point.) This seems to change as soon as one takes into account user functions. While most immutable functions really seem to be small and their execution fast, stable functions often hide complex sql (sometimes combined with if-then-else or other program flow logic). So irrespective of caching to prevent evaluation across statements, within a single statement, is there a strong reason why for example in WHERE col = f(const) with f() declared as immutable or stable and without an index on col, f() still gets called for every row? Or is this optimization just not done yet? Joachim