From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: EXPLAIN progress info |
Date: | 2008-07-03 13:11:30 |
Message-ID: | 486CD002.9010906@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
I like this idea in general. I'm envisioning a cool explain display in
pgAdmin that's updated live, as the query is executed, showing how many
tuples a seq scan in the bottom, and an aggregate above it, has
processed. Drool.
Currently the interface is that you open a new connection, and signal
the backend using the same mechanism as a query cancel. That's fine for
the interactive psql use case, but seems really heavy-weight for the
pgAdmin UI I'm envisioning. You'd have to poll the server, opening a new
connection each time. Any ideas on that? How about a GUC to send the
information automatically every n seconds, for example?
Other than that, this one seems to be the most serious issue:
Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> There are downsides:
>
> Insurmountable ones at that. This one already makes it a non-starter:
>
>> a) the overhead of counting rows and loops is there for every query execution,
>> even if you don't do explain analyze.
I wouldn't be surprised if the overhead of the counters turns out to be
a non-issue, but we'd have to see some testing of that. InstrEndLoop is
the function we're worried about, right?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-07-03 14:04:51 | Re: page macros cleanup |
Previous Message | daveg | 2008-07-03 12:55:01 | Re: [PATCHES] pg_dump lock timeout |