"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Here's a question then - what is the _drawback_ to having 1024 wal_buffers
> as opposed to 8?
Waste of RAM? You'd be better off leaving that 8 meg available for use
as general-purpose buffers ...
regards, tom lane
-
> I don't think this is based on a useful test for wal_buffers. The
> wal_buffers setting only has to be large enough for the maximum amount
> of WAL log data that your system emits between commits, because a commit
> (from anyone) is going to flush the WAL data to disk (for everyone).
> So a benc
> I don't think this is based on a useful test for wal_buffers. The
> wal_buffers setting only has to be large enough for the maximum amount
> of WAL log data that your system emits between commits, because a commit
> (from anyone) is going to flush the WAL data to disk (for everyone).
> So a benc
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I've just spent the last day and a half trying to benchmark our new database
> installation to find a good value for wal_buffers. The quick answer - there
> isn't, just leave it on the default of 8.
I don't think this is based on a useful te
On Thu, 2003-02-13 at 00:16, Christopher Kings-Lynne wrote:
> Even if you look at the attached charts and you think that 128 buffers are
> better than 8, think again - there's nothing in it. Next time I run that
> benchmark it could be the same, lower or higher. And the difference between
> the w
Christopher Kings-Lynne wrote:
> I'm not sure what I could test next. Does FreeBSD support anything other
> than fsync? eg. fdatasync, etc. I can't see it in the man pages...
You are already getting the best default for your OS. It say 'fsync'
for default, but the comment says the default is O
