I wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>> I believe this could usefully (and transparently to clients) be changed
>> so that Bind on the unnamed statement does _not_ store the plan back in
>> the unnamed statement's context, but instead produces a plan which is
>> only used _for that specific portal_.
> That seems OK to me, since we document the unnamed statement/portal as
> being optimized for one-shot execution. Unfortunately it's probably
> less than a trivial change, because the planner never assumes that
> Params are constants; that would have to be changed somehow.
I've applied a patch to do this --- the planner change turned out to be
pretty trivial after all.
The infrastructure for the former planning method (using the first
Bind's parameters as sample values for estimation, but not as constants)
is still there, but it's not being used now. Does anyone want to argue
for changing things to plan named statements that way? I'm of two minds
about it myself; you can make a good case that it'd usually be a win,
but it's also not hard to envision scenarios where it'd be a loss.
regards, tom lane