From: | Darcy Buskermolen <darcy(at)wavefire(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Neil Conway <neilc(at)samurai(dot)com> |
Subject: | Re: Progress bar updates |
Date: | 2006-07-19 15:54:33 |
Message-ID: | 200607190854.34677.darcy@wavefire.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wednesday 19 July 2006 07:33, Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >> In practice, if a query is taking long enough for this feature to be
> >> interesting, making another connection and looking to see what's
> >> happening is not a problem, and it's likely to be the most practical way
> >> anyway for many clients.
> >
> > It would be the most practical way for a DBA to monitor an application.
> > But it's not going to be convenient for clients like pgadmin or psql.
>
> [ shrug... ] Let me explain it to you this way: a progress counter
> visible through pg_stat_activity is something that might possibly get
> done in time for 8.2. If you insist on having the other stuff right
> off the bat as well, it won't get done this cycle.
Having the progress, or estimated time of completion in pg_stat_activity
sounds like a good starting point, the rest of the desired features can be
bolted on top of this down the road
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Darcy Buskermolen
Wavefire Technologies Corp.
http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759
From | Date | Subject | |
---|---|---|---|
Next Message | korry | 2006-07-19 15:59:35 | Loading the PL/pgSQL debugger (and other plugins) |
Previous Message | Andrew Dunstan | 2006-07-19 15:48:49 | Re: Patch process? |