Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 759C4B5DC1B
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 27 May 2011 21:26:02 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 10241-02
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Sat, 28 May 2011 00:25:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pw0-f46.google.com (mail-pw0-f46.google.com
	[209.85.160.46])
	by mail.postgresql.org (Postfix) with ESMTP id 08625B5DC12
	for <pgsql-performance@postgresql.org>;
	Fri, 27 May 2011 21:25:53 -0300 (ADT)
Received: by pwi15 with SMTP id 15so1005400pwi.19
	for <pgsql-performance@postgresql.org>;
	Fri, 27 May 2011 17:25:53 -0700 (PDT)
Received: by 10.142.187.2 with SMTP id k2mr432365wff.33.1306541943719;
	Fri, 27 May 2011 17:19:03 -0700 (PDT)
Received: from [10.10.3.129] (71-6-94-66.static-ip.telepacific.net
	[71.6.94.66])
	by mx.google.com with ESMTPS id x8sm1669701wfx.19.2011.05.27.17.19.02
	(version=SSLv3 cipher=OTHER); Fri, 27 May 2011 17:19:02 -0700 (PDT)
Subject: Re: The shared buffers challenge
From: Jeff Davis <pgsql@j-davis.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
In-Reply-To: <BANLkTimPC-K_o8XNn1hK4ZgBrTGO_Z6RDw@mail.gmail.com>
References: <BANLkTimPC-K_o8XNn1hK4ZgBrTGO_Z6RDw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 27 May 2011 17:19:01 -0700
Message-ID: <1306541941.32559.119.camel@jdavis-ux.asterdata.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201105/409
X-Sequence-Number: 43918

On Thu, 2011-05-26 at 09:31 -0500, Merlin Moncure wrote:
> Where they are most helpful is for masking of i/o if
> a page gets dirtied >1 times before it's written out to the heap

Another possible benefit of higher shared_buffers is that it may reduce
WAL flushes. A page cannot be evicted from shared_buffers until the WAL
has been flushed up to the page's LSN ("WAL before data"); so if there
is memory pressure to evict dirty buffers, it may cause extra WAL
flushes.

I'm not sure what the practical effects of this are, however, but it
might be an interesting thing to test.

Regards,
	Jeff Davis