Re: Performance of query (fwd)

Tom Lane wrote:

>I've thought about that ... but am not sure whether it wouldn't create
>as many problems as it solves. What are the consequences when the
>planner's pre-evaluation yields a different result from what actually
>happens at runtime? Hardly an unlikely scenario when dealing with
>stuff like now().
>
But isn't now() supposed to return the same value within the same
transaction?
Isn't that a guarantee, that it won't change between pre-evaluation and
actual execution?

> (And for actually constant expressions, say
>sin(pi), the result already does get folded to a constant. So only
>the nontrivial cases are left to think about.)
>
>
>In the case of functions with side-effects (think nextval()), the
>planner *must not* speculatively evaluate the function. We could
>introduce another function property-flag, like IMMUTABLE or STRICT,
>to govern this ... but I'm not sure it's worth the trouble.
>
>

I must be missing something here - isn't it enough to use the same logic
as when deciding whether the function output can be usedfor index scan?
In 7.2 conditions like 'where stamp < now()' were refusing to use the
index, because now() isn't immutable (cacheable)... I see that it is
fixed in 7.3 by adding another
flag - STABLE... It looks like the planner is now able to use the index
as long as the function is not volatile.
Can't the same criteria be applied to that pre-evaluation decision?

Dima