DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=KWBojDgr5aT1Xs1cvBOWfYm5qY5F7xfOhzpfeJPiliVrKM8svdSH5TzHGDj+A89OTPzXLg6tlHCPRJFZiMw+s4IIedlrlTMWnMuS0xPItmilgqk+ll/CdLmHR+WfOTTM7gTS5NnilFtfbnGeRJOjtJRcDBv5FmIYQNhIn8Q1v0I=;
References: 
 <CANs8QJb=nDR0=xSLx0E1LMs7uOYup6j4Ya-r4ReKdJCSbVFqHw@mail.gmail.com>
	<CAFj8pRDJu4-6ZDVttqePbZv4euCMDLT=N0T5L0DmA6uv_yCbLQ@mail.gmail.com>
	<CAFj8pRAROuxPQ5=v3BrLw1jLTC8HYV4be7gSAsQ90=BrRY+Spw@mail.gmail.com>
	<CANs8QJYt3C6TptfzEbCMSJvEwHh1prrtFhpNgXyc9P0z5ApANw@mail.gmail.com>
Message-ID: <1363632425.31395.YahooMailNeo@web162906.mail.bf1.yahoo.com>
Date: Mon, 18 Mar 2013 11:47:05 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: effective_cache_size on 32-bits postgres
To: Rodrigo Barboza <rodrigombufrj@gmail.com>,
	Pavel Stehule <pavel.stehule@gmail.com>
Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: 
 <CANs8QJYt3C6TptfzEbCMSJvEwHh1prrtFhpNgXyc9P0z5ApANw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Rodrigo Barboza <rodrigombufrj@gmail.com> wrote:

> So setting this as half of ram, as suggested in postgres tuning
> webpage should be safe?

Half of RAM is likely to be a very bad setting for any work load.=20
It will tend to result in the highest possible number of pages
duplicated in PostgreSQL and OS caches, reducing the cache hit
ratio.=A0 More commonly given advice is to start at 25% of RAM,
limited to 2GB on Windows or 32-bit systems or 8GB otherwise.=A0 Try
incremental adjustments from that point using your actual workload
on you actual hardware to find the "sweet spot".=A0 Some DW
environments report better performance assigning over 50% of RAM to
shared_buffers; OLTP loads often need to reduce this to prevent
periodic episodes of high latency.

--=20
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance