pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Needs discussion of pg_xlog
3+ messages / 3 participants
[nested] [flat]

* Needs discussion of pg_xlog
@ 2016-12-01 15:00  robert@interactive.co.uk
  0 siblings, 1 reply; 3+ messages in thread

From: robert@interactive.co.uk @ 2016-12-01 15:00 UTC (permalink / raw)
  To: pgsql-docs

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.4/static/runtime-config-file-locations.html
Description:

In various places (e.g. stackoverflow), I've seen people suggest having
pg_xlog ion a different disk (i.e. not in /var/lib/pgsql/9.X/data).

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.

If this IS a good idea, then "Server Configuration / File Locations" is
where it should be discussed: in particular, why is it a good idea, and how
does it affect backups (and in particular base backups to a standby server).

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


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Needs discussion of pg_xlog
@ 2016-12-01 16:56  Joshua D. Drake <jd@commandprompt.com>
  parent: robert@interactive.co.uk
  0 siblings, 1 reply; 3+ messages in thread

From: Joshua D. Drake @ 2016-12-01 16:56 UTC (permalink / raw)
  To: robert@interactive.co.uk; pgsql-docs

On 12/01/2016 07:00 AM, robert@interactive.co.uk wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.4/static/runtime-config-file-locations.html
> Description:
>
> In various places (e.g. stackoverflow), I&#39;ve seen people suggest having
> pg_xlog ion a different disk (i.e. not in /var/lib/pgsql/9.X/data).
>
> The only mention of this that I&#39;ve seen is in Section 29.5 (WAL Internals),
> and that just says &quot;it is advantageous...&quot;, with no explanation.
>
> If this IS a good idea, then &quot;Server Configuration / File Locations&quot; is
> where it should be discussed: in particular, why is it a good idea, and how
> does it affect backups (and in particular base backups to a standby server).

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

JD


>


-- 
Command Prompt, Inc.                  http://the.postgres.company/
                         +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.


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



^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Needs discussion of pg_xlog
@ 2016-12-01 18:50  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Joshua D. Drake <jd@commandprompt.com>
  0 siblings, 0 replies; 3+ messages in thread

From: Tom Lane @ 2016-12-01 18:50 UTC (permalink / raw)
  To: Joshua D. Drake <jd@commandprompt.com>; +Cc: robert@interactive.co.uk; 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&#39;ve seen is in Section 29.5 (WAL Internals),
>> and that just says &quot;it is advantageous...&quot;, 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


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



^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2016-12-01 18:50 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-12-01 15:00 Needs discussion of pg_xlog robert@interactive.co.uk
2016-12-01 16:56 ` Joshua D. Drake <jd@commandprompt.com>
2016-12-01 18:50   ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox