Re: Migration study, step 1: bulk write performance optimization

> 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.