User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 29 Jul 2005 10:11:10 -0700
Subject: Re: Performance problems testing with Spamassassin
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Cc: "Andrew McMillan" <andrew@catalyst.net.nz>,
	"Matthew Schumacher" <matt.s@aptalaska.net>,
	pgsql-performance@postgresql.org
Message-ID: <BF0FB13E.A3F4%llonergan@greenplum.com>
In-Reply-To: <20050729132319.GA13680@alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Alvaro,

On 7/29/05 6:23 AM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote:

> On Fri, Jul 29, 2005 at 03:01:07AM -0400, Luke Lonergan wrote:
> 
>> I guess we see the real culprit here.  Anyone surprised it's the WAL?
> 
> So what?  Are you planning to suggest people to turn fsync=false?

That's not the conclusion I made, no.  I was pointing out that fsync has a
HUGE impact on his problem, which implies something to do with the I/O sync
operations.  Black box bottleneck hunt approach #12.
 
> With fsync off, there's no
> work _at all_ going on, not just the WAL -- heap/index file fsync at
> checkpoint is also skipped.  This is no good.

OK - so that's what Tom is pointing out, that fsync impacts more than WAL.

However, finding out that fsync/no fsync makes a 400% difference in speed
for this problem is interesting and relevant, no?

- Luke