Re: EXPLAIN progress info

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

In response to

Browse pgsql-patches by date

  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