Progress indication prototype - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Progress indication prototype
Date
Msg-id 1282022387.10562.18.camel@vanquo.pezone.net
Whole thread Raw
Responses Re: Progress indication prototype  (Stephen Frost <sfrost@snowman.net>)
Re: Progress indication prototype  ("Erik Rijkers" <er@xs4all.nl>)
Re: Progress indication prototype  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Re: Progress indication prototype  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-hackers
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?

Other comments?

Attachment

pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: security label support, part.2
Next
From: Jaime Casanova
Date:
Subject: Re: Per-column collation, proof of concept