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:Agent M (age@themactionfaction.com)
Date:Jul 19, 2006 7:40:47 pm
List:org.postgresql.pgsql-hackers

Why make it so complicated?

There could be a guc to indicate that the client is interested in progress updates. For the execution phase, elog(INFO,...) could be emitted for each major plan node. (The client would probably run the explain plan beforehand or it would be embedded in the elog).

During the downloading of the rows, the client would display the bar relative to the number of estimated rows returned.

-M

On Jul 18, 2006, at 2:35 PM, Gregory Stark wrote:

Has anyone looked thought about what it would take to get progress bars from clients like pgadmin? (Or dare I even suggest psql:)

My first thought would be a message like CancelQuery which would cause the backend to peek into a static data structure and return a message that the client could parse and display something intelligent. Various commands would then stuff information into this data structure as they worked.

¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM age@themactionfaction.com ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬