From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: Volatility - docs vs behaviour?
Date: Mon, 30 Jun 2014 11:49:23 -0400
Message-ID: <10762.1404143363@sss.pgh.pa.us> (raw)
In-Reply-To: <53B12CE7.5090506@2ndquadrant.com>
References: <53B12CE7.5090506@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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....
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig@2ndquadrant.com, pavel.stehule@gmail.com
Subject: Re: Volatility - docs vs behaviour?
In-Reply-To: <10762.1404143363@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox