Re: EXPLAIN ANALYZE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: EXPLAIN ANALYZE
Date
Msg-id 23154.1165792196@sss.pgh.pa.us
Whole thread Raw
In response to Re: EXPLAIN ANALYZE  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: EXPLAIN ANALYZE
Re: EXPLAIN ANALYZE
Re: EXPLAIN ANALYZE
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> The EA case is pretty straightforward though;

Well, no its not, as you'll recall if you re-read the prior discussions.
The killer problem is that it's unclear whether the early termination of
the query represents an error condition or not.  If it's not an error
then you've got a serious problem for non-SELECT queries (which EA
actually executes, remember) --- you'll have allowed an incompletely
executed update to become committed, which is as good a definition of
"data corruption" as I can come up with offhand.  On the other hand,
if it is an error then delivering some results along with the error
requires serious contortion of the FE/BE protocol, libpq's response to
errors, etc.  To say nothing of what it might take to do it inside the
backend, which generally does not like doing anything interesting in an
already-aborted transaction.

We might be able to finesse the protocol problem by teaching EA to
respond to query cancel by emitting the data-so-far as a NOTICE (like it
used to do many moons ago), rather than a standard query result, then
allowing the query to error out.  However this'd be fairly unfriendly
for client-side tools that are expecting a query result.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: EXPLAIN ANALYZE
Next
From: "Simon Riggs"
Date:
Subject: Re: postgresql roadmap for horizontal scalability?