18 messages in org.postgresql.pgsql-hackersRe: Progress bar updates
FromSent OnAttachments
Gregory StarkJul 18, 2006 11:35 am 
Luke LonerganJul 18, 2006 11:44 am 
Dave PageJul 18, 2006 1:08 pm 
Andreas PflugJul 18, 2006 5:12 pm 
Neil ConwayJul 18, 2006 6:52 pm 
Tom LaneJul 18, 2006 8:23 pm 
Josh BerkusJul 18, 2006 9:24 pm 
Greg StarkJul 19, 2006 2:18 am 
Hannu KrosingJul 19, 2006 2:33 am 
Dave PageJul 19, 2006 2:35 am 
Andreas PflugJul 19, 2006 5:23 am 
Tom LaneJul 19, 2006 7:33 am 
Darcy BuskermolenJul 19, 2006 8:54 am 
Andrew HammondJul 19, 2006 10:29 am 
Christopher Kings-LynneJul 19, 2006 6:38 pm 
Agent MJul 19, 2006 7:40 pm 
Csaba NagyJul 20, 2006 1:51 am 
Luke LonerganJul 20, 2006 8:36 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Progress bar updatesActions...
From:Luke Lonergan (LLon@greenplum.com)
Date:Jul 20, 2006 8:36:32 am
List:org.postgresql.pgsql-hackers

This is how netezza and teradata do it and it works very well.

In each of their cases you can see a graphical representation of the plan with
progress for each stage.

For the command line it would be great to just dump the current status, which
would provide a snapshot of the explain analyze.

- Luke

Sent from my GoodLink synchronized handheld (www.good.com)

-----Original Message----- From: Csaba Nagy [mailto:na@ecircle-ag.com] Sent: Thursday, July 20, 2006 04:52 AM Eastern Standard Time To: Andrew Hammond Cc: postgres hackers Subject: Re: [HACKERS] Progress bar updates

We already have EXPLAIN ANALYZE. Perhaps the right way to do this is something that provides similar output. I could see something that looks like EXPLAIN for the parts that have not yet executed, something reasonable to show progress of the currently active part of the plan (current time, rows, loops), and EXPLAIN ANALYZE output for the parts which have been completed.

Now this is something that would really help testing a system, by dynamically seeing the plans of queries which run too long. That combined with the ability to see the values of bind parameters would be a useful debug aid.

Cheers, Csaba.

---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives?

http://archives.postgresql.org