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,
.
- 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
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 during
query
Ü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 to a
backend
-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 would be the most practical way
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
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 anyway for
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 problem, and
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 is there
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.
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).
Has anyone looked thought about what it would take to get progress bars from
clients like pgadmin? (Or dare I even suggest psql:)
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
-hackers@postgresql.org
Subject:[HACKERS] Progress bar updates
Has anyone looked thought about what it would take to get progress bars from
clients like pgadmin? (Or dare I even suggest psql:)
My first thought would be a message like CancelQuery which would cause the
backend to peek
-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 and 1
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...
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
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 wrong
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
18 matches
Mail list logo
