From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
 Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: Volatility - docs vs behaviour?
In-reply-to: <53B12CE7.5090506@2ndquadrant.com>
References: <53B12CE7.5090506@2ndquadrant.com>
Comments: In-reply-to Craig Ringer <craig@2ndquadrant.com>
 message dated "Mon, 30 Jun 2014 17:24:55 +0800"
Date: Mon, 30 Jun 2014 11:49:23 -0400
Message-ID: <10762.1404143363@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Craig Ringer <craig@2ndquadrant.com> writes:
> The docs say:

> "For best optimization results, you should label your functions with the
> strictest volatility category that is valid for them."

Yeah ...

> ... but I recall discussion here suggesting that in fact IMMUTABLE
> functions may not be inlined where you'd expect, e.g.
> http://www.postgresql.org/message-id/CAFj8pRBF3Qr7WtQwO1H_WN=hhFGk0semwhdE+ODz3iyv-TroMQ@mail.gmail.com

The reason that case behaved surprisingly was exactly that the user had
violated the above bit of documentation, ie, he'd marked the function
*incorrectly* as being immutable when in fact its contained functions
were only stable.

> I know STRICT can prevent inlining (unfortunately, though necessarily),
> but it seems inexplicable that IMMUTABLE should.

I don't see why you find that inexplicable.  If the planner were to
inline this function, it would then fail to reduce a call with constant
argument to a constant, which is presumably what the user desires from
marking it immutable (questions of correctness in the face of timezone
changes notwithstanding).  Just as we "keep the wrapper on" when it's
necessary to hide possible non-strictness of the body of a function,
we must do so when inlining would raise the visible volatility of an
expression.

It's true that the above-quoted bit of advice presumes that you correctly
identify the "strictest volatility category that is valid" for a given
function.  If you're too lazy or uninformed to do that, it might be
better to leave the settings at defaults (volatile/nonstrict) and hope
the planner can figure out that it's safe to inline anyway.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance