try to dump-restore your 'slow' database,
this might help if your db or filesystem gets too fragmented.
On Tue, 30 May 2006 10:31:08 -0400
"mcelroy, tim" <[EMAIL PROTECTED]> wrote:
> Good morning,
>
> I have identical postgres installations running on identical machines. Dual
> Core AMD Optero
Title: RE: [PERFORM] pg_dump issue
I did carry it down to the subdirectory level but only included the total for brevity. I'll paste the complete readout at the end of the email. I'll try the "vmstat 1" as you suggest next time the backups run. If the Eng staff find
"mcelroy, tim" <[EMAIL PROTECTED]> writes:
> The du . -h in $PGDATA showed PROD001 at 9.1G and Prod0002 at 8.8G so
> they're pretty much the same, one would think the smaller one should be
> faster. Yes, the backup files are identical in size.
Hmph. You should carry the "du" analysis down to th
Title: RE: [PERFORM] pg_dump issue
Thanks Tom. I have scheduled vacuums as follows and all have run without error.
Mon - Thu after-hours: vacuumdb -z -e -a -v On Fridays I add the -f option vacuumdb -z -e -a -v -f
The du . -h in $PGDATA showed PROD001 at 9.1G and Prod0002 at 8.8G
"mcelroy, tim" <[EMAIL PROTECTED]> writes:
> I have identical postgres installations running on identical machines. Dual
> Core AMD Opteron(tm) Processor 870 , 16GB RAM, Red Hat Linux 3.2.3-20 and
> 120GB worth of disk space on two drives.
> Recently, I have noticed that my nightly backups take l
Title: pg_dump issue
Good morning,
I have identical postgres installations running on identical machines. Dual Core AMD Opteron(tm) Processor 870 , 16GB RAM, Red Hat Linux 3.2.3-20 and 120GB worth of disk space on two drives.
Recently, I have noticed that my nightly backups take longer on
