Re: explain doesn't work with execute using

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: explain doesn't work with execute using
Date: 2008-06-01 17:23:45
Message-ID: 23613.1212341025@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/6/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-06-01 17:43:22 Re: Core team statement on replication in PostgreSQL
Previous Message Merlin Moncure 2008-06-01 17:19:10 Re: Core team statement on replication in PostgreSQL