2008/6/1 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> 2008/6/1 Tom Lane <tgl@sss.pgh.pa.us>:
>>> This argument seems entirely bogus. How are they any more constant
>>> than in the other case? The value isn't going to change for the life
>>> of the portal in either case.
>
>> this is true Tom, but problem is in EXPLAIN. I thing, so my and your
>> solution are little bit incorect. We solve result, not reason. We have
>> problem, bacause plan doesn't carry parameter's flags, and with
>> EXPLAIN planner is called two times with different param's flags.
>
> [ shrug... ] Well, I'm willing to change the code as you suggest,
> but if you're thinking that this will make EXPLAIN exactly reproduce
> the plan that would be generated for a plain SELECT invoked in the
> same context, you're still mistaken. It doesn't account for the
> effects of the fast-start-cursor option. And for what you seem to
> want EXPLAIN to do here, it probably shouldn't. The whole thing
> seems pretty unprincipled to me ...
>
It's not best, and it's surprise for me, so EXPLAIN can be different
then real plan. It's basic tool for identification of plpgsql
procedure's performance problems. So this can be short fix and point
for ToDo?
Regards
Pavel Stehule
> regards, tom lane
>