Re: [HACKERS] More benchmarking of wal_buffers - Mailing list pgsql-performance

From Curt Sampson
Subject Re: [HACKERS] More benchmarking of wal_buffers
Date
Msg-id Pine.NEB.4.51.0302151732320.361@angelic-vtfw.cvpn.cynic.net
Whole thread Raw
In response to Re: [HACKERS] More benchmarking of wal_buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Thu, 13 Feb 2003, Tom Lane wrote:

> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > What I mean is say you have an enterprise server doing heaps of transactions
> > with lots of work.  If you have scads of RAM, could you just shove up
> > wal_buffers really high and assume it will improve performance?
>
> There is no such thing as infinite RAM (or if there is, you paid *way*
> too much for your database server).  My feeling is that it's a bad
> idea to put more than you absolutely have to into single-use buffers.
> Multi-purpose buffers are usually a better use of RAM.

Well, yes, but he was talking about 8 MB of WAL buffers. On a machine
with, say, 2 GB of RAM, that's an insignificant amount (0.4% of your
memory), and so I would say that it basically can't hurt at all. If your
log is on the same disk as your data, the larger writes when doing a big
transaction, such as a copy, might be a noticable win, in fact.

(I was about to say that it would seem odd that someone would spend that
much on RAM and not splurge on an extra pair of disks to separate the
WAL log, but then I realized that we're only talking about $300 or so
worth of RAM....)

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

pgsql-performance by date:

Previous
From: Curt Sampson
Date:
Subject: Re: [HACKERS] WAL replay logic (was Re: Mount options for
Next
From: Scott Cain
Date:
Subject: Re: [Gmod-schema] Re: performace problem after VACUUM