On Thu, Jul 2, 2009 at 2:32 AM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> I think the only resonable solution would be to consider the estimated
> cost of each node and then compute what percentage complete each node
Well you can do better for some nodes. A sequential scan for example
can tell you exactly what percentage of the way through its scan it
is. A sort node that's fnished the sort can produce an value based on
both the estimate of the relative costs of the sort vs reading the
results and the actual percentage progress reading the results.
So I think it has to come down to another ExecProcNode method the way
I had it arranged in my patch that actually implemented this.
I was partly waiting for the other patch which multiplexed signals
onto fewer actual unix signals to go through. And for XML explain
plans to go through. Once we have those then I think my patch is
actually nearly there, it just needs some additional tweaking of the
heuristics for more plan types.
Then comes the fun part of figuring out a useful UI for psql and
pgadmin. Personally I'm happy for psql to just print the plan whenever
the user hits siginfo. I think an apt-style curses progress bar would
be unecessarily heavyweight for the lightweight vision I have for
psql. But I know others have more ambitious visions for psql.
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2009-07-02 12:41:33|
|Subject: Re: HEAD is open for 8.5 development|
|Previous:||From: Robert Haas||Date: 2009-07-02 11:48:23|
|Subject: Re: First CommitFest: July 15th|