Re: [SPAM?] Re: PG8 Tuning - Mailing list pgsql-performance

From Josh Berkus
Subject Re: [SPAM?] Re: PG8 Tuning
Date
Msg-id 200508160912.32263.josh@agliodbs.com
Whole thread Raw
In response to Re: [SPAM?] Re: PG8 Tuning  ("Jeffrey W. Baker" <jwbaker@acm.org>)
Responses Re: [SPAM?] Re: PG8 Tuning
Re: [SPAM?] Re: PG8 Tuning
List pgsql-performance
Jeff,

> > 4) pg_xlog: If you're pg_xlog is on a spindle is *only* for pg_xlog
> > you're better off.
>
> Like Mr. Stone said earlier, this is pure dogma.  In my experience,
> xlogs on the same volume with data is much faster if both are on
> battery-backed write-back RAID controller memory.  Moving from this
> situation to xlogs on a single normal disk is going to be much slower in
> most cases.

The advice on separate drives for xlog (as is all advice on that web page) is
based on numerous, repeatable tests at OSDL.

However, you are absolutely correct in that it's *relative* advice, not
absolute advice.   If, for example, you're using a $100,000 EMC SAN as your
storage you'll probably be better off giving it everything and letting its
controller and cache handle disk allocation etc.   On the other hand, if
you're dealing with the 5 drives in a single Dell 6650, I've yet to encounter
a case where a separate xlog disk did not benefit an OLTP application.

For Solaris, the advantage of using a separate disk or partition is that the
mount options you want for the xlog (including forcedirectio) are
considerably different from what you'd use with the main database.

--
Josh Berkus
Aglio Database Solutions
San Francisco

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Need for speed
Next
From: John A Meinel
Date:
Subject: Re: Need for speed