From: Pierre C <lists@peufeu.com>
To: Jaime Casanova <jcasanov@systemguards.com.ec>
To: Tadipathri Raghu <traghu.dba@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Why Wal_buffer is 64KB
Date: Thu, 25 Mar 2010 19:14:38 +0100
Message-ID: <op.u94yaoixeorkce@localhost> (raw)
In-Reply-To: <3073cc9b1003251015x590e962ata59dadbb58b42ce5@mail.gmail.com>
References: <645d9d71003250801o246439a0j93c7b568786e98de@mail.gmail.com>
<3073cc9b1003251015x590e962ata59dadbb58b42ce5@mail.gmail.com>
If you do large transactions, which emits large quantities of xlog, be
aware that while the previous xlog segment is being fsynced, no new writes
happen to the next segment. If you use large wal_buffers (more than 16 MB)
these buffers can absorb xlog data while the previous segment is being
fsynced, which allows a higher throughput. However, large wal_buffers also
mean the COMMIT of small transactions might find lots of data in the
buffers that noone has written/synced yet, which isn't good. If you use
dedicated spindle(s) for the xlog, you can set the walwriter to be
extremely aggressive (write every 5 ms for instance) and use fdatasync.
This way, at almost every rotation of the disk, xlog gets written. I've
found this configuration gives increased throughput, while not
compromising latency, but you need to test it for yourself, it depends on
your whole system.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lists@peufeu.com, jcasanov@systemguards.com.ec, traghu.dba@gmail.com
Subject: Re: Why Wal_buffer is 64KB
In-Reply-To: <op.u94yaoixeorkce@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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