Message-ID: <4DAD9C98.5090707@2ndQuadrant.com>
Date: Tue, 19 Apr 2011 10:30:48 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: How to configure a read-only database server?
References: <BANLkTinA9B=80cG8R=132RTxF52K=Mdfuw@mail.gmail.com>
In-Reply-To: <BANLkTinA9B=80cG8R=132RTxF52K=Mdfuw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 04/18/2011 06:08 PM, Stefan Keller wrote:
> * What about wal_level and archive_mode?
>    

Presumably you don't care about either of these.  wal_level=minimal, 
archive_mode=off.

The other non-obvious thing you should do in this situation is do all 
the database maintenance in one big run after the data is loaded, 
something like:

VACUUM FREEZE ANALYZE;

Otherwise you will still have some trickle of write-activity going on, 
not always efficiently, despite being in read-only mode.  It's because 
of what's referred to as Hint Bits:  
http://wiki.postgresql.org/wiki/Hint_Bits

VACUUMing everything will clean those us, and freezing everything makes 
sure there's no old transactions to concerned about that might kick off 
anti-wraparound autovacuum.

The only other thing you probably want to do is set checkpoint_segments 
to a big number.  Shouldn't matter normally, but when doing this freeze 
operation it will help that execute quickly.  You want a lower 
maintenance_work_mem on a read-only system than the master too, possibly 
a higher shared_buffers as well.  It's all pretty subtle beyond the big 
parameters you already identified.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books