Re: Performace Optimization for Dummies - Mailing list pgsql-performance

From Carlo Stonebanks
Subject Re: Performace Optimization for Dummies
Date
Msg-id efh26m$2fd$1@news.hub.org
Whole thread Raw
In response to Performace Optimization for Dummies  ("Carlo Stonebanks" <stonec.register@sympatico.ca>)
Responses Re: Performace Optimization for Dummies  (Steve Atkins <steve@blighty.com>)
Re: Performace Optimization for Dummies  ("Jim C. Nasby" <jim@nasby.net>)
Re: Performace Optimization for Dummies  (Matthew Nuzum <matthew.nuzum@canonical.com>)
Re: Performace Optimization for Dummies  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-performance
> are you using the 'copy' interface?

Straightforward inserts - the import data has to transformed, normalised and
de-duped by the import program. I imagine the copy interface is for more
straightforward data importing. These are - buy necessity - single row
inserts.

> thats a tough question.  my gut says that windows will not scale as
> well as recent linux kernels in high load environments.

But not in the case of a single import program trying to seed a massive
database?

> hearing good things about the woodcrest. pre-woodcrest xeon (dempsey
> down) is outclassed by the opteron.

Need to find a way to deterimine the Xeon type. The server was bought in
early 2006, and it looks like woodcrest was form July.

> 1. can probably run fsync=off during the import
> 2. if import is single proecess, consider temporary bump to memory for
> index creation. or, since you have four cores consider having four
> processes import the data somehow.
> 3. turn off stats collector, stats_command_string, stats_row_level,
> and autovacuum during import.

Very helpful, thanks.

Carlo



pgsql-performance by date:

Previous
From: "Carlo Stonebanks"
Date:
Subject: Re: Performace Optimization for Dummies
Next
From: Steve Atkins
Date:
Subject: Re: Performace Optimization for Dummies