Re: "iscachable" functions - Mailing list pgsql-general

From Arguile
Subject Re: "iscachable" functions
Date
Msg-id 1045261712.457.115.camel@broadswd
Whole thread Raw
In response to "iscachable" functions  (Eric B.Ridge <ebr@tcdi.com>)
List pgsql-general
On Fri, 2003-02-14 at 15:14, Eric B.Ridge wrote:
> For the "iscachable" parameter of CREATE FUNCTION, the 7.2.x
> documentation states:
>     "Iscachable indicates that the function always returns the same result
> when given the same argument values (i.e., it does not do database
> lookups or otherwise use information not directly present in its
> parameter list). The optimizer uses iscachable to know whether it is
> safe to pre-evaluate a call of the function."

In CS terms this means the function is referentially transparent.

>
> But where is this cache?  Is it per backend connection, or is it shared
> among all backends?  Also, is there a way to invalidate this cache or
> otherwise expire the values?

The 'cache' is within whatever you used the function for. Let's say you.

   CREATE INDEX foo ON bar( lower(qux) );

When we create this index Pg calls lower(qux) for each record in bar. It
computes each value and 'caches' it as the key.

So when you call:

   SELECT * FROM bar WHERE lower(qux) = lower('aBBa')

The only work to do is lower('aBBa') to 'abba', then do a straight index
lookup. Figuring out lower(qux) for each record in bar has already been
'cached'.

To invalidate the cache you'd have to recreate the index. There's no
automatic dependency tracking I'm aware of.

The same idea applies to other things -- like SPs -- that can be
'compiled'.

>
> thanks!
>
> eric
>
>

Side note:
----------
For a list of iscachable functions (drop the pg_catalog bit for pre
7.3):

    SELECT proname FROM pg_catalog.pg_proc WHERE proisstrict = true;


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: operators and bit field
Next
From: Patrick Nelson
Date:
Subject: Re: pgtcl way of specifying a user [SOLVED]