Craig Ringer <craig@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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
