Re: Needs discussion of pg_xlog - Mailing list pgsql-docs

From Tom Lane
Subject Re: Needs discussion of pg_xlog
Date
Msg-id 29385.1480618213@sss.pgh.pa.us
Whole thread Raw
In response to Re: Needs discussion of pg_xlog  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-docs
"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've seen is in Section 29.5 (WAL Internals),
>> and that just says "it is advantageous...", with no explanation.

> The reason it can be advantageous is that pg_xlog has a different write
> 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


pgsql-docs by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Needs discussion of pg_xlog
Next
From: Robert Haas
Date:
Subject: Re: monitoring.sgml - clarify length of query text displayed in pg_stat_statements