From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Joshua D. Drake" <jd@commandprompt.com>
cc: robert@interactive.co.uk, pgsql-docs@postgresql.org
Subject: Re: Needs discussion of pg_xlog
In-reply-to: <5414c450-db82-8169-d5cf-f33339d0944c@commandprompt.com>
References: <20161201150006.4377.8523@wrigleys.postgresql.org>
 <5414c450-db82-8169-d5cf-f33339d0944c@commandprompt.com>
Comments: In-reply-to "Joshua D. Drake" <jd@commandprompt.com>
	message dated "Thu, 01 Dec 2016 08:56:20 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29384.1480618213.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 01 Dec 2016 13:50:13 -0500
Message-ID: <29385.1480618213@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On 12/01/2016 07:00 AM, robert@interactive.co.uk wrote:
>> The only mention of this that I&#39;ve seen is in Section 29.5 (WAL Inte=
rnals),
>> and that just says &quot;it is advantageous...&quot;, with no explanatio=
n.

> The reason it can be advantageous is that pg_xlog has a different write=20
> profile that $PGDATA. The WAL is written sequentially versus randomly.

Yeah.  The traditional understanding of that was you wanted to keep a
write head positioned over the current end-of-WAL, which of course only
applies to spinning rust.

It's still true that under heavy update loads, your I/O volume to WAL is
probably comparable to your I/O volume to everything else, which might
justify a separate SSD just on write bandwidth grounds.  But seek delays
aren't part of the calculation anymore.

			regards, tom lane


--=20
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs