From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Progress indication prototype |
Date: | 2010-09-20 06:14:08 |
Message-ID: | 4C96FBB0.1000500@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I had a small play with this. Pretty cool to be able to track progress
for COPY and VACUUM jobs. For some reason I could never elicit any
numbers (other than the default Nan) for a query (tried 'SELECT count(*)
FROM pgbench_accounts' but figured aggregates probably don't qualify as
simple, and also 'SELECT * FROM pgbench_accounts').
I'm thinking that complex queries is precisely where people would want
to see this sort of indicator - but maybe have a read of:
http://research.microsoft.com/pubs/76171/progress.pdf
This paper seems to suggest that there are real classes of query where a
useful progress indicator is going to be extremely hard to construct.
However it may still be a useful feature to have for all those other
queries!
Also I'm inclined to agree with Robert and think that a more accurate,
more performance obtrusive but settable on demand implementation is the
way to go.
Cheers
Mark
On 17/08/10 17:19, Peter Eisentraut wrote:
> Here is a small prototype for a query progress indicator.
>
> Past discussions seemed to indicate that the best place to report this
> would be in pg_stat_activity. So that's what this does. You can try it
> out with any of the following (on a sufficiently large table): VACUUM
> (lazy) (also autovacuum), COPY out from table, COPY in from file,
> table-rewriting ALTER TABLE (e.g., add column with default), or a very
> simple query. Run the command, and stare at pg_stat_activity (perhaps
> via "watch") in a separate session.
>
> More can be added, and the exact placement of the counters is debatable,
> but those might be details to be worked out later. Note, my emphasis
> here is on maintenance commands; I don't plan to do a progress
> estimation of complex queries at this time.
>
> Some thoughts:
>
> - Are the interfaces OK?
>
> - Is this going to be too slow to be useful?
>
> - Should there be a separate switch to turn it on (currently
> track_activities)?
>
> - How to handle commands that process multiple tables? For example,
> lazy VACUUM on a single table is pretty easy to track (count the block
> numbers), but what about a database-wide lazy VACUUM?
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-09-20 06:22:29 | Re: [HACKERS] wip: functions median and percentile |
Previous Message | David Fetter | 2010-09-20 05:11:02 | Re: [HACKERS] wip: functions median and percentile |