Date: Mon, 20 Mar 2006 17:35:00 +0100
To: "Mikael Carneholm" <Mikael.Carneholm@wirelesscar.com>,
	pgsql-performance@postgresql.org
Subject: Re: Migration study, step 1: bulk write performance optimization
References: <7F10D26ECFA1FB458B89C5B4B0D72C2B088286@sesrv12.wirelesscar.com>
From: PFC <lists@peufeu.com>
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.s6p0cm0icigqcu@apollo13>
In-Reply-To: <7F10D26ECFA1FB458B89C5B4B0D72C2B088286@sesrv12.wirelesscar.com>
User-Agent: Opera M2/8.51 (Linux, build 1462)

> using a 16kb block  size (for read performance) will probably be  
> considered as well.

	Hm, this means that when postgres wants to write just one 8k page, the OS  
will have to read 16k, replace half of it with the new block, and write  
16k again... I guess it should be better to stick with the usual block  
size. Also, it will have to read 16k every time it rally wants to read one  
page... which happens quite often except for seq scan.

> NOTE: this machine/configuration is NOT what we will be using in  
> production if the study turns out OK, it's just supposed to work as a  
> development machine in the first phase whose purpose more or less is to  
> get familiar with configurating Postgres and see if we can get the  
> application up and running (we will probably use a 64bit platform and

	Opteron xDDD

	Use XFS or Reiser... ext3 isn't well suited for this. use noatime AND  
nodiratime.

	It's safe to turn off fsync while importing your data.
	For optimum speed, put the WAL on another physical disk.

	Look in the docs which of maintenance_work_mem, or work_mem or sort_mem  
is used for index creation, and set it to a very large value, to speed up  
that index creation. Create your indexes with fsync=off also.