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:Dave Page (dpa@vale-housing.co.uk)
Date:Jul 18, 2006 1:08:26 pm
List:org.postgresql.pgsql-hackers

-----Original Message----- From: pgsq@postgresql.org [mailto:pgsq@postgresql.org] On Behalf Of Gregory Stark Sent: 18 July 2006 19:36 To: pgsq@postgresql.org Subject: [HACKERS] Progress bar updates

For a first cut this "data structure" could just be a float between 0 and 1. Or perhaps it should be two integers, a "current" and an "estimated final". That would let the client do more intelligent things when the estimates change for the length of the whole job.

Hi Greg,

I would vote for the latter so that we could give more meaningful feedback - for example, when vacuuming you might give a scale of 0 to <num tables>. In cases such as COPY where you mightn't have any idea of an upper bound, then a simple heartbeat could be supplied so at least the client could count rows (or 100's of rows) processed or whatever.

It would certainly allow us to present a nicer user experience in pgAdmin :-)

Regards, Dave.