15

I am regularly saving and later restoring a smallish PostgreSQL database, which is used for testing. Its data is updated regularly as a result of tests, then a new dump must be made, and the dumps are regularly used to recreate the database in a well-defined state.

I noted that the dump (using pg_dump -Fc database) only takes a few seconds, but the restore (pg_restore -d database) takes about a minute. This seems weird. I would have expected both to take about the same time (assuming both tasks are I/O-bound).

Is there some problem with the restore? Could I maybe make it faster? Or is it normal for restore to take much longer than dump? (And if yes, then why?)

The dump file usually has about 3-4 MiB; the DBMS is PostgreSQL V8.4, running on a Pentium4 3GHz with 1GiB RAM under Ubuntu Linux.

Improve this question

2 Answers 2

Reset to default
13

The content of an index is not part of the backup, only the definition of the index. And that will only take a few bytes. When the index is created during restore and all data is indexed, it will be much bigger. This will take time, but it depends on your situation how much time.

pg_restore does have an option for concurrent restore (as of version 8.4), use --jobs=number-of-jobs

Improve this answer
9
  • Interesting, thanks. Is there a way to dump the index as well, to speed up the restore (at the cost of a larger dump file)?
    – sleske
    Mar 2, 2011 at 12:34
  • No, the content of the index can't be part of the backup. For a very small database like yours (3-4 MiB), it shouldn't be a problem anyway.
    – Frank Heikens
    Mar 2, 2011 at 12:43
  • Additional information: pg_dump doesn't have access to the content of an index. pg_dump uses SELECT statements to get all content of the tables and content of the system tables to create the backup. It's "just" a wrapper around some SELECT statements and some functions to write the results to disk.
    – Frank Heikens
    Mar 2, 2011 at 12:58
  • @Frank: Thanks. Didn't know about pg_dump's implementation. In our case, speeding up the restore would be helpful, because it needs to run repeatedly as part of automated tests, so bringing it down from 1 minute to say 10s would help. But apparently that's not feasible. I'll have to find a different solution...
    – sleske
    Mar 2, 2011 at 13:34
  • 2
    @sleske you might try with the filesystem backup approach. This should preserve indexes and, in addition, probably run a bit faster for both backup and restore
    – Stefano
    May 27, 2011 at 12:41
7

For a restore, the database has to do a lot of additional work:

Some things come to mind immediately:

  • Writing is slower than reading
  • Parsing the input takes time
  • Updating indexes and other internal structures
  • Maintaining referential integrity

Not sure if this amounts to that time difference, though.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .