Progress indication prototype

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Progress indication prototype
Дата
Msg-id 1282022387.10562.18.camel@vanquo.pezone.net
обсуждение исходный текст
Ответы 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>)
Список 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?

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: security label support, part.2
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: Per-column collation, proof of concept