Thread: pg_dump for table with bytea takes a long time

Dumping a database which contains a table with a bytea column takes approximately 25 hours and 45 minutes.  The database has 26 tables in it. The other 25 tables take less than 5 minutes to dump so almost all time is spent dumping the bytea table.

prd1=# \d ybnet.ebook_master;

     Table "ybnet.ebook_master"

    Column    |  Type   | Modifiers

--------------+---------+-----------

 region_key   | integer | not null

 book_key     | integer | not null

 pub_sequence | integer | not null

 section_code | integer | not null

 pagenbr      | integer | not null

 pdffile      | bytea   |

Indexes:

    "ebook_master_pkey" PRIMARY KEY, btree (book_key, pub_sequence, section_code, pagenbr, region_key)

Foreign-key constraints:

    "FK1_book_year" FOREIGN KEY (book_key, pub_sequence, region_key) REFERENCES ybnet.book_year(book_key, pub_sequence, region_key)

    "FK1_ebook_section" FOREIGN KEY (section_code) REFERENCES ybnet.ebook_section(sectioncode)

Tablespace: "ebook"

The tablespace ebook is 65504295 bytes in size and the ebook_master table has 61-1GB files associated to it.

The command to dump the database is:

pg_dump --file=$DUMP_FILE --format=c --data-only --verbose -–host=ybcdrdbp01 $DATABASE

I also perform a hot backup of this database using pg_start_backup(), tar, and pg_stop_backup().  It takes only 20 minutes to create a tar ball of the entire 62GB.  I like the speed of this method, but it does not allow me to restore 1 table at a time.

The version of postgres is PostgreSQL 8.0.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2

The machine has 4 Xeon 3.00 GHz processors with hyper-threading on and 4GB of memory.  Postgres is supported by two file systems connected to an EMC SAN disk array.  One 2 GB one for the log files and a second 500 GB one for the data and indexes.  All output files for the backup files are placed onto the 500 GB volume group and then backed up to an external storage manager.

Portions of the config file are:

shared_buffers = 16384

work_mem = 8192

maintenance_work_mem = 16384

max_fsm_pages = 512000

max_fsm_relations = 1000

fsync = true

# - Checkpoints -

checkpoint_segments = 20

# - Planner Cost Constants -

effective_cache_size = 262144

random_page_cost = 3

I am looking for ideas for making the backup of the above table much faster.