One last question. Are there any pitfalls if I roll my own ability to check for duplicate calls?
Since I am using my own defined data type, and my own function, I could
do this by:
1. in my data type X, adding fields for: a table oid, a row oid, a copy
of a reference to the last 2nd argument, and a copy of the last result
(in my case a double)
2. in my function (which takes two X args), if the new
table/row/ref-2nd-arg match the last data (saved in the first arg), then
return the last result, otherwise compute the new result and save this
info to use on the next call
This should enable only a single computation of the data for any given
row as long as the same args are used as parameters.
But, is this safe, or have any pitfalls I would need to look out for?
Thanks!
Bob
--- On Thu, 2/3/11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Subject: Re: [GENERAL] how to avoid repeating expensive computation in select
> To: "Bob Price" <rjp_email@yahoo.com>
> Cc: "Bill Moran" <wmoran@potentialtech.com>, pgsql-general@postgresql.org
> Date: Thursday, February 3, 2011, 5:33 PM
> Bob Price <rjp_email@yahoo.com>
> writes:
> > If I set the COST of expensivefunc high, and label it
> IMMUTABLE, will the query executor note that the two
> invocations to expensivefunc have the same inputs so it can
> only call it once and re-use the result the second time?
>
> No. There is a myth prevalent among certain wishful
> thinkers that
> IMMUTABLE does something like that, but it doesn't.
> IMMUTABLE only
> licenses the planner to fold a call *with constant
> arguments* into a
> constant result, by executing the function once before the
> query
> actually starts. Textually distinct calls of a
> function are not folded
> together in any case.
>
>
> regards, tom lane
>
