> >> This bothers me a bit, because in
> >> fact the effects if any of the tested query would have been rolled
> >> back. Not sure we have any choice though. If we expose the error
> >> then we'll have problems with clients not showing the EXPLAIN
> >> results.
>
> > I think we should leave
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> This bothers me a bit, because in
>> fact the effects if any of the tested query would have been
>> rolled back. Not sure we have any choice though. If we
>> expose the error then we'll have problems with clients not
>> showing the E
> This bothers me a bit, because in
> fact the effects if any of the tested query would have been
> rolled back. Not sure we have any choice though. If we
> expose the error then we'll have problems with clients not
> showing the EXPLAIN results.
I think we should leave it in top level, thro
On Thu, 2006-06-08 at 13:51 -0400, Tom Lane wrote:
> I wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
> >> question is what we do when one is not available.
>
> > The least bad alternative I've heard is to let EXPLAIN ANAL
Tom Lane wrote:
> A possible objection to this is that running a query inside a
> subtransaction might have different/worse performance than running it
> at top level. I don't recall any severe bottlenecks of that kind but
> that doesn't mean there aren't any (Alvaro, any comments?)
Nope, nothin
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> 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 posi
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 <[EMA
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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
Tom Lane <[EMAIL PROTECTED]> writes:
> After we've printed the results, we have a bit of a problem: if
> ExplainCancelPending is set, we now need to abort the transaction. It
> would not do at all to allow an incompletely executed UPDATE to commit.
> I experimented with throwing an elog() at the
I wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> A full EXPLAIN ANALYZE is always desirable - we agree on that. The
>> question is what we do when one is not available.
> The least bad alternative I've heard is to let EXPLAIN ANALYZE print
> out stats-so-far if the query is canceled by contro
10 matches
Mail list logo
