On Thu, Jun 04, 2009 at 09:48:17AM -0400, Tom Lane wrote:
> Sam Mason <sam@samason.me.uk> writes:
> > If it's an SQL function and marked as IMMUTABLE it should (I believe
> > anyway) get inlined somewhere along the line and take no more overhead
> > than writing it out in full.
>
> Actually, if you're intending that a SQL function be inline-able then
> it's best *not* to mark it as IMMUTABLE (nor STRICT either). If the
> marking matches the behavior of the contained expression then it
> doesn't matter, but if the marking is stricter than the expression
> it will prevent inlining.
Why would strictness alter planning? I was under the impression that it
only affected evaluation, i.e. it doesn't need to call the code if any
parameter is NULL.
That said, I was just saying what I've normally done. I've just checked
the docs[1] and they may need rewording:
For best optimization results, you should label your functions with
the strictest volatility category that is valid for them.
> Rather than think hard, I usually just don't
> annotate the SQL function at all.
Hum, I only tend to annotate small functions where I can easily verify
what they're doing. I think I picked up this practice when PG wasn't
inlining things I thought it should be and saying it was immutable made
it work. Not sure when I got this habit, if I could drop it now that
would be nice.
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current/static/xfunc-volatility.html