Re: Performance of query (fwd)

Ok, I see now...
I did not know that those cached plans survived transaction end...

Thanks for clarification.

Dima

Tom Lane wrote:

>Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
>
>
>>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?
>>
>>
>
>What's that have to do with it? Plans have to be good for longer than
>one transaction --- see prepared statements and plpgsql plan caching.
>
>
>
>>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?
>>
>>
>
>No, see above. If we could, we'd not have bothered to make a
>distinction between IMMUTABLE and STABLE functions, we'd just allow the
>planner to fold them all to constants at plan time. (STABLE functions
>aren't actually guaranteed to hold still even across one transaction,
>only across one command in a transaction. But that's not really
>relevant to the planner's problem.)
>
> regards, tom lane
>
>