Re: EXPLAIN ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Neil Conway" <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EXPLAIN ANALYZE
Date: 2006-12-10 23:09:56
Message-ID: 23154.1165792196@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Simon Riggs" <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-12-10 23:19:39 Re: postgresql roadmap for horizontal scalability?
Previous Message Simon Riggs 2006-12-10 22:46:00 Re: EXPLAIN ANALYZE