On Thu, 13 Feb 2003, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 imp
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 i
Kevin Brown <[EMAIL PROTECTED]> writes:
> What happens when the only transaction running emits more WAL log data
> than wal_buffers can handle? A flush happens when the WAL buffers
> fill up (that's what I'd expect)? Didn't find much in the
> documentation about it...
A write, not a flush (ie, w
Tom Lane wrote:
> "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
"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
-
> "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 ...
What I mean is say you have an
> 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
Hi Everyone,
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.
The numbers just swing up and down so much it's impossible to say that one
setting is be
12 matches
Mail list logo
