Message-ID: <4C2C6721.2010000@2ndquadrant.com>
Date: Thu, 01 Jul 2010 06:00:01 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
	rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Jignesh Shah <jkshah@gmail.com>
CC: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>,
	Robert Haas <robertmhaas@gmail.com>,
	Dimitri Fontaine <dfontaine@hi-media.com>,
	Josh Berkus <josh@agliodbs.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: PostgreSQL as a local in-memory cache
References: <AANLkTikj3pglP8uqPdUBHZ3bDQq86aG6MYzDUUyurTez@mail.gmail.com>
	<201006300139.o5U1dHN12285@momjian.us>
	<AANLkTiljNjw1EIpqWbhXTJZyYPJ7Vb3jsvEmA9NUv9Ys@mail.gmail.com>
In-Reply-To: <AANLkTiljNjw1EIpqWbhXTJZyYPJ7Vb3jsvEmA9NUv9Ys@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  On 6/30/2010 2:21 PM, Jignesh Shah wrote:
> If the underlying WAL disk is SSD then it seems I can get 
> synchronous_commit=on to work faster than
> synchronous_commit=off..

The first explanation that pops to mind is that synchronous_commit is 
writing all the time, which doesn't have the same sort of penalty on 
SSD.  Whereas if you turn it off, then there are some idle periods where 
the SSD could be writing usefully, but instead it's buffering for the 
next burst instead.  The importance of that can be magnified on 
operating systems that do their own buffering and tend to lag behind 
writes until they see an fsync call, like is the case on Linux with ext3.