"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 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.
What I suggested was introducing a new FE/BE message type for analyze query
plans. Then clients that recognize it can use it to display the query plan
without interfering with the query results. Clients that don't know what to do
with it would have to just ignore it.
Then we could introduce as many ways of triggering these messages as we like.
A GUC to trigger one every n seconds, a FE/BE message like QueryCancel, say,
QueryProbe which triggers one when the user presses a button in pgadmin or C-t
(SIGINFO) in psql, etc.
I was thinking that it should be more structured than the current block of
text that clients receive. I had in mind to make it equivalent to a PGResult
so the various bits of data would be in different named columns. This would
let GUI clients like pgadmin interpret the results more effectively and make
it easier for us to add data without worrying about information overload on
the user's side.
And the query would keep operating. Canceling the query and statement_timeout
would both be entirely orthogonal to requesting analyze results.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
