• 15
name

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191

Backtrace:

File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

pg_restore taking much longer than pg_dump

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.

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

  • 9
Reply Report
    • 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: 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...
      • 2
    • 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)?
      • 2
    • 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.

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.

  • 4
Reply Report

Trending Tags