From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Gregory Stark" <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Progress bar updates |
Date: | 2006-07-18 20:08:49 |
Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E40154C074@ratbert.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Gregory Stark
> Sent: 18 July 2006 19:36
> To: pgsql-hackers(at)postgresql(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-07-18 20:18:27 | Re: plpython sets |
Previous Message | Andrew Dunstan | 2006-07-18 19:46:32 | Re: [HACKERS] 8.2 features? |