.
- Luke
Sent from my GoodLink synchronized handheld (www.good.com)
-Original Message-
From: Csaba Nagy [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 04:52 AM Eastern Standard Time
To: Andrew Hammond
Cc: postgres hackers
Subject:Re: [HACKERS] Progress bar
> We already have EXPLAIN ANALYZE. Perhaps the right way to do this is
> something that provides similar output. I could see something that
> looks like EXPLAIN for the parts that have not yet executed, something
> reasonable to show progress of the currently active part of the plan
> (current time
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).
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. Even a web
server may want to, for example, stream ajax code updating a progress bar
until it has results and then stream the ajax to display the results. H
Neil Conway wrote:
> > I would suggest starting with utility functions like index builds or COPY
> > which would have to be specially handled anyways. Handling all optimizable
> > queries in a single generic implementation seems like something to tackle
> > only
> > once the basic infrastructure i
On Wednesday 19 July 2006 07:33, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> 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
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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 anywa
Josh Berkus wrote:
Andreas,
Some weeks ago I proposed a PROGRESS parameter for COPY, to enable
progress feedback via notices. tgl thinks nobody needs that...
Well, *Tom* doesn't need it. What mechanism did you propose to make this
work?
Extended the parser to accept that keyword,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Greg Stark
> Sent: 19 July 2006 10:19
> To: Tom Lane
> Cc: Neil Conway; Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Progress bar updates
>
> It
Ühel kenal päeval, K, 2006-07-19 kell 05:18, kirjutas Greg Stark:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > I'm not quite sure what you're suggesting; presumably you'd need to open
> > > another client connection to send the "status report" message
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm not quite sure what you're suggesting; presumably you'd need to open
> > another client connection to send the "status report" message to a
> > backend (since a backend will not be polling its input socket durin
Andreas,
> Some weeks ago I proposed a PROGRESS parameter for COPY, to enable
> progress feedback via notices. tgl thinks nobody needs that...
Well, *Tom* doesn't need it. What mechanism did you propose to make this
work?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
Neil Conway <[EMAIL PROTECTED]> writes:
> I'm not quite sure what you're suggesting; presumably you'd need to open
> another client connection to send the "status report" message to a
> backend (since a backend will not be polling its input socket during
> query execution). That just seems like the
On Tue, 2006-07-18 at 14:35 -0400, Gregory Stark wrote:
> 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.
I'm not quite sure what you're s
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:)
Some weeks ago I proposed a PROGRESS parameter for COPY, to enable
progress feedback via notices. tgl thinks nobody needs that...
Regards,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
> Sent: 18 July 2006 19:36
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Progress bar updates
>
>
> For a first cut this "data structure" could just be a float
> between 0
+1
Looked, talked it through, it's a very important feature to BI users.
- Luke
Sent from my GoodLink synchronized handheld (www.good.com)
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 02:38 PM Eastern Standard Time
To: pgsql-ha
17 matches
Mail list logo
