Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2008-07-03 14:04:51
Subject: Re: page macros cleanup
Previous:From: davegDate: 2008-07-03 12:55:01
Subject: Re: [PATCHES] pg_dump lock timeout

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group