Re: Progress bar updates

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.

In response to

Browse pgsql-hackers by date

  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?