Re: "iscachable" functions

Поиск
Список
Период
Сортировка
От Arguile
Тема Re: "iscachable" functions
Дата
Msg-id 1045261712.457.115.camel@broadswd
обсуждение исходный текст
Ответ на "iscachable" functions  (Eric B.Ridge <ebr@tcdi.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: operators and bit field
Следующее
От: Patrick Nelson
Дата:
Сообщение: Re: pgtcl way of specifying a user [SOLVED]