From: | David Wheeler <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: IMMUTABLE? |
Date: | 2006-05-16 18:00:27 |
Message-ID: | 719F1E6C-4695-4FD2-A73B-0E3AE173B8F0@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Arjen van der Meijden | 2006-05-16 18:08:32 | Re: Pgsql (and mysql) benchmark on T2000/Solaris and some |
Previous Message | Joachim Wieland | 2006-05-16 16:55:14 | Re: IMMUTABLE? |