Date: Fri, 12 Feb 2010 17:11:06 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: aidan@highrise.ca, jesper@krogh.cc, hannu@krosing.net,
	pgsql-performance@postgresql.org
Subject: Re: moving pg_xlog -- yeah, it's worth it!
Message-ID: <20100212201106.GH3737@alvh.no-ip.org>
References: <4B750193020000250002F22D@gw.wicourts.gov>
	<20100212140348.GA3737@alvh.no-ip.org>
	<20100212141036.GB3737@alvh.no-ip.org>
	<4B75162E020000250002F235@gw.wicourts.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B75162E020000250002F235@gw.wicourts.gov>
User-Agent: Mutt/1.5.20 (2009-06-14)

Kevin Grittner wrote:
> Alvaro Herrera <alvherre@commandprompt.com> wrote:

> > Actually, a transaction that performed no writes doesn't get a
> > commit WAL record written, so it shouldn't make any difference at
> > all.
>  
> Well, concurrent to the web application is the replication.  Would
> asynchronous commit of that potentially alter the pattern of writes
> such that it had less impact on the reads?

Well, certainly async commit would completely change the pattern of
writes: it would give the controller an opportunity to reorder them
according to some scheduler.  Otherwise they are strictly serialized.

> I'm thinking, again, of
> why the placement of the pg_xlog on a separate file system made such
> a dramatic difference to the read-only response time -- might it
> make less difference if the replication was using asynchronous
> commit?

Yeah, I think it would have been less notorious, but this is all
theoretical.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.