Re: Migration study, step 1: bulk write performance optimization - Mailing list pgsql-performance

From PFC
Subject Re: Migration study, step 1: bulk write performance optimization
Date
Msg-id op.s6p0cm0icigqcu@apollo13
Whole thread Raw
In response to Migration study, step 1: bulk write performance optimization  ("Mikael Carneholm" <Mikael.Carneholm@WirelessCar.com>)
List pgsql-performance
> 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.



pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Best OS & Configuration for Dual Xeon w/4GB &
Next
From: "Reimer"
Date:
Subject: Re: Query Feromance