Re: [Proposal] Progress bar for pg_dump/pg_restore - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [Proposal] Progress bar for pg_dump/pg_restore
Date
Msg-id 558894DE.20807@BlueTreble.com
Whole thread Raw
In response to Re: [Proposal] Progress bar for pg_dump/pg_restore  (Craig Ringer <craig@2ndquadrant.com>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Jim Nasby
Date:
Subject: Re: proposal: row_to_array function