Re: Postgresql Performance on an HP DL385 and

From: Michael Stone <mstone+postgres(at)mathom(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql Performance on an HP DL385 and
Date: 2006-08-15 17:25:21
Message-ID: 20060815172519.GT2900@mathom.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Aug 15, 2006 at 11:25:24AM -0500, Jim C. Nasby wrote:
>Well, if the controller is caching with a BBU, I'm not sure that order
>matters anymore, because the controller should be able to re-order at
>will. Theoretically. :) But this is why having some actual data posted
>somewhere would be great.

You're missing the point. It's not a question of what happens once it
gets to the disk/controller, it's a question of whether the xlog write
has to compete with some other write activity before the write gets to
the disk (e.g., at the filesystem level). If you've got a bunch of stuff
in a write buffer on the OS level and you try to push the xlog write
out, you may have to wait for the other stuff to get to the controller
write cache before the xlog does. It doesn't matter if you don't have to
wait for the write to get from the controller cache to the disk if you
already had to wait to get to the controller cache. The effect is a
*lot* smaller than not having a non-volatile cache, but it is an
improvement. (Also, the difference between ext2 and xfs for the xlog is
pretty big itself, and a good reason all by itself to put xlog on a
seperate partition that's small enough to not need journalling.)

Mike Stone

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Stone 2006-08-15 17:26:46 Re: Postgresql Performance on an HP DL385 and
Previous Message Jim C. Nasby 2006-08-15 16:56:02 Re: Inner Join of the same table