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
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 |