Re: EXPLAIN ANALYZE
От | Tom Lane |
---|---|
Тема | Re: EXPLAIN ANALYZE |
Дата | |
Msg-id | 23154.1165792196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: EXPLAIN ANALYZE ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: EXPLAIN ANALYZE
Re: EXPLAIN ANALYZE Re: EXPLAIN ANALYZE |
Список | 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 по дате отправления: