Re: "iscachable" functions

From: Arguile <arguile(at)lucentstudios(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: "iscachable" functions
Date: 2003-02-14 22:28:31
Message-ID: 1045261712.457.115.camel@broadswd
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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;

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-14 22:29:48 Re: operators and bit field
Previous Message Tom Lane 2003-02-14 22:25:09 Re: In 7.3.1, will I be able to reindex toast?