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