Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN - Mailing list pgsql-hackers

From A.M.
Subject Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN
Date
Msg-id 38022.128.2.103.215.1149793684.squirrel@localhost
Whole thread Raw
In response to Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I think what he meant was "a separate EXPLAIN-CANCEL message" on a
cancel-type connection, which would be completely backwards compatible.
Old clients simply wouldn't be able to use the special EXPLAIN cancel,
just like it is now.

On Thu, June 8, 2006 3:01 pm, Tom Lane wrote:
> Gregory Stark <gsstark@mit.edu> writes:
>
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Would it be possible to make a whole new protocol message for EXPLAIN
>> results?
>
> I'm really unwilling to get into that.  For one thing, that would
> absolutely positively break *all* use of EXPLAIN from un-fixed clients,
> whether you were trying to stop early or not.
>
>> The reason I'm suggesting that is because it might make it easier to
>> implement the SIGINFO handler that sends incremental EXPLAIN results on
>> demand that I was describing earlier.
>
> Doesn't matter, because that's not happening ;-)  SIGINFO isn't
> portable, and even if it were, a signal handler couldn't possibly generate
> EXPLAIN output (remember those catalog accesses).
>
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>
> http://www.postgresql.org/docs/faq
>
>




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] drop if exists remainder
Next
From: Tom Lane
Date:
Subject: Re: ADD/DROP INHERITS