Re: 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 so
they're pretty much the same, one would think the smaller one should be
faster. Yes, the backup files are identical in size. BTW - this is
postgres 8.0.1. Stuck at this due to "that is the latest postgresql version
certified by our vendor's application".

I'm hoping the Engineering staff can find something system related as I
doubted and still doubt that it's a postgres issue.

Tim

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, May 30, 2006 11:16 AM
To: mcelroy, tim
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] pg_dump issue

"mcelroy, tim" <tim(dot)mcelroy(at)bostonstock(dot)com> 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 longer on one
machine
> than on the other. I back up five (5) databases totaling 8.6GB in size.
On
> Prod001 the backups take app. 7 minutes, on Prod002 the backups take app.
26
> minutes! Quite a discrepancy.

Are the resulting backup files identical? Chasing down the reasons for
any diffs might yield some enlightenment.

One idea that comes to mind is that Prod002 is having performance
problems due to table bloat (maybe a missing vacuum cron job or
some such). A quick "du" on the two $PGDATA directories to check
for significant size differences would reveal this if so.

regards, tom lane