Thread: how much left for restore?
Is there a way to know/estimate how much is left to complete a restore? It would be enough just knowing which part of the file is being restored (without causing too much extra IO, that will definitively put my notebook on its knee). Next time I try a restore on this box is there anything I could tweak in pg config to make it faster? For dev only... could I just stop the dev server, copy the *files* on flash and mount them on the notebook? thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo writes: > Is there a way to know/estimate how much is left to complete a > restore? Not sure on plain ASCII files but if your pg_dump used Fc then at restore you can pass the -v flag.
On Mon, 11 Jan 2010 12:30:45 -0500 Francisco Reyes <lists@stringsutils.com> wrote: > Ivan Sergio Borgonovo writes: > > > Is there a way to know/estimate how much is left to complete a > > restore? > > Not sure on plain ASCII files but if your pg_dump used Fc then at > restore you can pass the -v flag. It get a bit better but even knowing what are the largest tables it is hard to get an estimate of how much is missing before complete restore. I'm really looking at rough figures... even a: I've read 40% of the file will give a more usable information than: I've already loaded table A. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo writes: > It get a bit better but even knowing what are the largest tables it > is hard to get an estimate of how much is missing before complete > restore. Agree. Also building indexes can also take quite some time. > I'm really looking at rough figures... even a: I've read 40% of the > file will give a more usable information than: I've already loaded > table A. I don't believe there is anything like that and have not see anything in the TODO list (that I recall) either. It likely is not easy to implement. For starters to get such an estimate you would need to know how much data a table has. That would require to do a pass to get size or somehow store table size on the restore for the estimate. Then you have indexes.. they are just one line on the backup, but can take quite a while to build depending on size. For the foreseable future -v is likely all that is and will be available.
On Fri, Jan 08, 2010 at 11:28:15AM +0100, Ivan Sergio Borgonovo wrote: > Is there a way to know/estimate how much is left to complete a > restore? maybe something like "pv" would help? http://www.ivarch.com/programs/pv.shtml -- Sam http://samason.me.uk/
Sam Mason writes: > maybe something like "pv" would help? > > http://www.ivarch.com/programs/pv.shtml I think it may help the OP, but indexes are still going to be a rough spot.. if large table has several indexes the output from pv will be missleading.
On Mon, 11 Jan 2010 18:36:18 +0000 Sam Mason <sam@samason.me.uk> wrote: > On Fri, Jan 08, 2010 at 11:28:15AM +0100, Ivan Sergio Borgonovo > wrote: > > Is there a way to know/estimate how much is left to complete a > > restore? > maybe something like "pv" would help? > http://www.ivarch.com/programs/pv.shtml Nice. Start to look more as what I was looking for... and yeah... I'm aware it could be misleading. It would be nice to have it integrated in pg_restore/dump. If the file is compressed pg_* may make a better work to give an estimate. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Friday 08 January 2010 11.28:15 Ivan Sergio Borgonovo wrote:
> It would be enough just knowing which part of the file is being
> restored (without causing too much extra IO, that will definitively
> put my notebook on its knee).
Highly platform dependent, but has helped me a lot recently with various
(non-pg) tasks: on recent Linux, /proc/<pid>/fdinfo/ contains the current
file pointer, so you can see how far in the dump file pg has read.
(Assuming the restore reads the dump file just once from start to finish.)
Same problem as the other solutions with index creation etc. of course.
cheers
-- vbi
--
And those meanies used what we said to you and they misconstrued it to
mean what we said, and that's so unfair.
-- SCO lawyers about IBM (paraphrased - groklaw)