Greetings all!
Interesting. This brings up a quick question. If a "prepare" statement is
run, and then values are passed in, does the plan stay the same regardless
of the values? Or is a second pass made to re-optimize the plan?
Regards!
Ed
On Wed, 11 Jun 2003, Dmitry Tkach wrote:
> 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@openratings.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
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
