From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: auto-sizing wal_buffers |
Date: | 2011-01-17 03:58:01 |
Message-ID: | AANLkTimZVFNcCuQ+iDCs2aCQ0HXyf3WiAkYmUR6S9Vsc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 1/14/11 10:51 PM, Greg Smith wrote:
>>
>> ! Since the data is written out to disk at every transaction
>> commit,
>> ! the setting many only need to be be large enough to hold the
>> amount
>> ! of WAL data generated by one typical transaction. Larger values,
>> ! typically at least a few megabytes, can improve write performance
>> ! on a busy server where many clients are committing at once.
>> ! Extremely large settings are unlikely to provide additional
>> benefit.
>
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
I would turn it around and ask if there is any theoretical reason it
would not benefit?
(And if so, can they be cured soon?)
> Certainly there have been no test results to show any.
Did the tests show steady improvement up to 16MB and then suddenly
hit a wall? (And in which case, were they recompiled at a larger segment
size and repeated?) Or did improvement just peter out because 16MB is really
quite a bit and there was just no need for it to be larger independent
of segment size?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Colson | 2011-01-17 04:03:48 | Re: plperlu problem with utf8 [REVIEW] |
Previous Message | Josh Kupershmidt | 2011-01-17 03:40:32 | Re: psql: Add \dL to show languages |