From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: with (iscachable) |
Date: | 2001-10-31 02:19:46 |
Message-ID: | 3BDF5FC2.5E938C7E@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Reasonable definitions would be:
>
> 1. noncachable: must be called every time; not guaranteed to return same
> result for same parameters even within a query. random(), timeofday(),
> nextval() are examples.
>
> 2. fully cachable: function guarantees same result for same parameters
> no matter when invoked. This setting allows a call with constant
> parameters to be constant-folded on sight.
Something like strlower() or metaphone() are perfect examples.
>
> 3. query cachable: function guarantees same result for same parameters
> within a single query, or more precisely within a single
> CommandCounterIncrement interval. This corresponds to the actual
> behavior of functions that execute SELECTs, and it's sufficiently strong
> to allow the function result to be used in an indexscan, which is what
> we really care about.
This is IMHO the important one. I would not presume to argue the scope, but as
someone who has spent the last year building entire systems on Postgres (and
loving every minute of it) I would really like a fairly reliable definition
from which someone can understand and predict the behavior.
Currently, it seems fairly reliable that "iscachable" functions are called once
per unique parameter within the scope of a select, and I like this behavior.
When/if it breaks I will have some work to do. (As observed with fairly simple
queries.)
>
> I'm by no means wedded to those names ... maybe someone can think of
> better terminology.
I kinda like the terminology I presented, "cacheable, non-cacheable,
persistent" but hey, they are only words. I don't think people will be
confused, "persistent" and "non-cacheable" are pretty obvious.
>
> > With the above definitions, it would make sense to have "iscacheable" as the
> > default for a function.
>
> I'd still vote for noncachable as the default; unsurprising behavior is
> to be preferred over maximum performance IMHO.
I've thought about this one, a lot, and I can totally see your point of view,
but it isn't clear to me that it would be surprising that a function would only
be called once per unique set of parameters per select. What do other databases
do?
From | Date | Subject | |
---|---|---|---|
Next Message | Horst Herb | 2001-10-31 03:37:29 | Re: Serious performance problem |
Previous Message | Bruce Momjian | 2001-10-31 01:54:54 | Re: Postings from Bruce and Olivier rejected ... |