Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group