On Mon, 2006-12-11 at 11:00 +0000, Gregory Stark wrote:
> "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.
I like the idea, but its more work than I really wanted to get into
right now.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com