From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-performance@lusis.org
Cc: PGSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Performance of pg_dump on PGSQL 8.0
Date: Wed, 14 Jun 2006 11:51:47 -0400
Message-ID: <26780.1150300307@sss.pgh.pa.us> (raw)
In-Reply-To: <44902165.7020502@lusis.org>
References: <44902165.7020502@lusis.org>
"John E. Vincent" <pgsql-performance@lusis.org> writes:
> I've watched the backup process and I/O is not a problem. Memory isn't a
> problem either. It seems that we're CPU bound but NOT in I/O wait.
Is it the pg_dump process, or the connected backend, that's chewing the
bulk of the CPU time? (This should be pretty obvious in "top".)
If it's the pg_dump process, the bulk of the CPU time is likely going
into compression --- you might consider backing off the compression
level, perhaps --compress=1 or even 0 if size of the dump file isn't
a big concern.
Another possibility if your LAN is reasonably fast is to run pg_dump on
a different machine, so that you can put two CPUs to work.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-performance@lusis.org
Subject: Re: Performance of pg_dump on PGSQL 8.0
In-Reply-To: <26780.1150300307@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox