ineffiency of pg_restore

From: Jie Liang <jie(at)stbernard(dot)com>
To: Jie Liang <jie(at)stbernard(dot)com>, 'Bruce Momjian ' <pgman(at)candle(dot)pha(dot)pa(dot)us>, 'Tom Lane ' <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'pgsql-admin(at)postgresql(dot)org '" <pgsql-admin(at)postgresql(dot)org>, "'pgsql-bugs(at)postgresql(dot)org'" <pgsql-bugs(at)postgresql(dot)org>
Subject: ineffiency of pg_restore
Date: 2002-08-12 22:30:06
Message-ID: 7C760DAA511DC74B99E7D22189F786F101BF2164@mail01.stbernard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

pg_restore give admin a lot of flexabilities, it can restore any object
from a single dump file. But if the table is very big, e.g. 2M records,
it will take a long time to restore because it use INSERTs.
I believe that if we can have following feature:
1. quick restore(use COPY not INSERTs),
2. restore related objects, e.g. when we restore a table, we can choose
to restore its indexes, triggers and related sequence etc.

that will be great, I expect that we have them in next version of release.

test log:

su-2.05$ time psql urldb<jurloldmail.out
You are now connected as new user jliang.
CREATE

real 0m0.662s
user 0m0.045s
sys 0m0.015s
su-2.05$ time pg_restore -cvt jurloldmail -d urldb urldb.out.020810
pg_restore: connecting to database for restore
pg_restore: dropping TABLE jurloldmail
pg_restore: connecting to database urldb as user jliang
pg_restore: creating TABLE jurloldmail
pg_restore: restoring data for table jurloldmail

real 0m6.880s
user 0m0.296s
sys 0m0.028s

10 times slower!!!

Jie Liang

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2002-08-12 22:38:26 Re: ineffiency of pg_restore
Previous Message Jie Liang 2002-08-12 22:16:51 inefficiency of pg_restore

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2002-08-12 22:38:26 Re: ineffiency of pg_restore
Previous Message pgsql-bugs 2002-08-12 22:11:31 Bug #736: Old bug is back!! Drop database bug