| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Taiki Kondo <tai-kondo(at)yk(dot)jp(dot)nec(dot)com> |
| Cc: | "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <aki-iwaasa(at)vt(dot)jp(dot)nec(dot)com>, Jan Urbański <wulczer(at)wulczer(dot)org> |
| Subject: | Re: [Proposal] Progress bar for pg_dump/pg_restore |
| Date: | 2015-06-22 23:06:06 |
| Message-ID: | 558894DE.20807@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-06-22 23:56:35 | Re: proposal: row_to_array function |
| Previous Message | Jim Nasby | 2015-06-22 22:23:48 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |