On Thu, Jun 04, 2009 at 09:48:17AM -0400, Tom Lane wrote: > Sam Mason <s...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
