Re: IMMUTABLE? - Mailing list pgsql-performance

From David Wheeler
Subject Re: IMMUTABLE?
Date
Msg-id 719F1E6C-4695-4FD2-A73B-0E3AE173B8F0@kineticode.com
Whole thread Raw
In response to Re: IMMUTABLE?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: IMMUTABLE?
List pgsql-performance
On May 15, 2006, at 21:31, Tom Lane wrote:

> Sure.  As I read it, that's talking about a static transformation:
> planner sees 2 + 2 (or if you prefer, int4pl(2,2)), planner runs the
> function and replaces the expression with 4.  Nothing there about
> memoization.

Oh, I see. So it's more like a constant or C macro.

> 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.)

Yes, but there are definitely programming cases where memoization/
caching definitely helps. And it's easy to tell for a given function
whether or not it really helps by simply trying it with CACHED and
without.

Would this be a simple thing to implement?

Best,

David

pgsql-performance by date:

Previous
From: Joachim Wieland
Date:
Subject: Re: IMMUTABLE?
Next
From: Arjen van der Meijden
Date:
Subject: Re: Pgsql (and mysql) benchmark on T2000/Solaris and some