On 06/30/2014 11:49 PM, Tom Lane wrote: > 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. Yes, I realise that's the case with this particular incident. It's the more general case I'm interested in - whether this can be true in general, not just when the user does something dumb. It sounds like you're saying that the behaviour observed here is specific to cases where the user incorrectly identifies the function volatility. In which case we don't care, that's fine, no problem here. My concern was only with whether the advice that the highest volatility category should be used is always true for *correct* immutable functions too. >> 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. If the input is constant, then clearly it should be evaluated and a constant substituted. If it _isn't_ a constant input, then why would STRICT inline when IMMUTABLE doesn't? > 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. I was unaware that the planner made any attempt to catch users' errors in marking the strictness of functions. I thought it pretty much trusted the user not to lie about the mutability of functions invoked indirectly. I'm not really sure where in the inlining code to look to figure that out. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
