Re: Performance problems testing with Spamassassin

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Andrew McMillan" <andrew(at)catalyst(dot)net(dot)nz>, "Matthew Schumacher" <matt(dot)s(at)aptalaska(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance problems testing with Spamassassin
Date: 2005-07-29 17:11:10
Message-ID: BF0FB13E.A3F4%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alvaro,

On 7/29/05 6:23 AM, "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Luke Lonergan 2005-07-29 17:13:41 Re: Performance problems testing with Spamassassin
Previous Message Matteo Beccati 2005-07-29 16:50:44 ltree <@ operator selectivity causes very slow plan