Re: What does this tell me?

Robert Treat <xzilla@users.sourceforge.net>

From: Robert Treat <xzilla@users.sourceforge.net>
To: Josh Berkus <josh@agliodbs.com>
Cc: Joe Conway <mail@joeconway.com>, Bruce Momjian <pgman@candle.pha.pa.us>, Sean Chittenden <sean@chittenden.org>, pgsql-performance@postgresql.org
Date: 2002-10-09T13:57:18Z
Lists: pgsql-performance
On Wed, 2002-10-09 at 01:22, Josh Berkus wrote:
> Joe,
> 
> > If that's the case, can you split the work up into multiple
> > functions, and execute them all from a shell script? Or perhaps even
> > offload some of the data massaging to perl or something? (It would be
> > easier to recommend alternate approaches with more details.)
> 
> I've already split it up into 11 functions, which are being managed
> through Perl with ANALYZE statements between.   Breaking it down
> further would be really unmanageable.
> 

If I read Tom's suggestion correctly, you should probably change these
to vacuum analyze instead of analyze. 

> Not to be mean or anything (after all, I just joined pgsql-advocacy),
> I'm getting *much* worse performance on large data transformations from
> PostgreSQL 7.2.1, than I get from SQL Server 7.0 on inferior hardware
> (at least, except where SQL Server 7.0 crashes). 

what?? that's blasphamy!! revoke this mans advocacy membership right
now!!  ;-)


I really am determined
> to prove that it's because I've misconfigured it, and I thank all of
> you for your help in doing so.
> 

FWIW I just ran into a similar situation where I was doing 6
simultaneous pg_restores of our production database on my local
workstation.  Apparently this pumps a lot of data through the wal logs. 
I did kick up the number of wal files, but I also ended up kicking up
the number of wal_buffers as well and that seemed to help.  

Robert Treat