Re: [Proposal] Progress bar for pg_dump/pg_restore

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [Proposal] Progress bar for pg_dump/pg_restore
Дата
Msg-id 558894DE.20807@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [Proposal] Progress bar for pg_dump/pg_restore  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 6/21/15 9:45 PM, Craig Ringer wrote:
>> And, I also understood your concern about "CREATE INDEX", but we have no way to get progress information of "CREATE
INDEX".
>> >At present, I think it may be good to refer to the same time as estimated time to execute "COPY TO".
> You could probably get a handwave-quality estimate by looking at the
> average column widths for the cols included in the index plus the
> number of tuples in the table. It'd be useless for expression indexes,
> partial indexes, etc, but you can't have everything...

Jan Urbański demonstrated[1] getting progress stats for long running 
queries[2] at pgCon 2013. Perhaps some of that code would be useful here 
(or better yet perhaps we could include at least the measuring portion 
of his stuff in core... ;)

[1] https://www.pgcon.org/2013/schedule/events/576.en.html
[2] https://github.com/wulczer/pg-progress
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: proposal: row_to_array function