From: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN |
Date: | 2006-06-08 19:08:04 |
Message-ID: | 38022.128.2.103.215.1149793684.squirrel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)mit(dot)edu> writes:
>
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-08 19:08:39 | Re: ADD/DROP INHERITS |
Previous Message | Alvaro Herrera | 2006-06-08 19:06:01 | Re: [PATCHES] drop if exists remainder |