Yes, but it does make an impact on decisions. For example, take the one I
was having a problem with. Understanding that the optimizer will make
certain assumptions about the distribution of values, and use this in the
estimator, and then realizing that for a specific set of values, no
changes will occurs makes a big impact. You have to now carefully plan and
_test_ both ways (using a prepared statement, vs always re-preparing each
statement in a loop) to determine where your best performance is.
In a perfect world, an optimizer would return a set of plans, or
alternatively, provide some bounds of values on when it would be better
to replan once the variables are known.
Another alternative would be to plan, and if a portion that is executed is
vastly off the original estimates, to replan the rest of the statements.
For example, the problem with my statement was not the internal select
(which, while estimated high, really did run fast), but that the actual
number of returned rows was much smaller than the planner had estimated.
If there could have been some kind of trigger to basically indicate "hey,
this is really, really off the estimate, let's take a moment to replan the
rest of the steps", then it would have probably run much better, at the
cost of a second pass through the planner.
Regards,
Ed
On Wed, 11 Jun 2003, Tom Lane wrote:
> Edmund Dengler <edmundd@eSentire.com> writes:
> > 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?
>
> AFAICS, the entire *point* of a prepared statement is that the plan is
> computed just once for multiple uses.
>
> regards, tom lane
>
