From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Neil Conway" <neilc(at)samurai(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EXPLAIN ANALYZE |
Date: | 2006-12-11 18:01:59 |
Message-ID: | 1165860119.3816.68.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2006-12-11 at 11:00 +0000, Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-11 18:05:24 | Re: Vacuum, analyze, and setting reltuples of pg_class |
Previous Message | Greg Sabino Mullane | 2006-12-11 17:35:57 | Re: Vacuum, analyze, and setting reltuples of pg_class |