Re: Dirty Buffer Writing [was Proposed LogWriter Scheme] - Mailing list pgsql-hackers

From Neil Conway
Subject Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]
Date
Msg-id 87k7ktpxqu.fsf@mailbox.samurai.com
Whole thread Raw
In response to Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  (Greg Copeland <greg@CopelandConsulting.Net>)
Responses Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  ("Curtis Faith" <curtis@galtair.com>)
List pgsql-hackers
Greg Copeland <greg@CopelandConsulting.Net> writes:
> Doesn't this also increase the likelihood that people will be running in
> a buffer-poor environment more frequently that I previously asserted,
> especially in very heavily I/O bound systems?  Unless I'm mistaken, that
> opens the door for a general case of why an aio implementation should be
> looked into.

Well, at least for *this specific sitation*, it doesn't really change
anything -- since FreeBSD doesn't implement POSIX AIO as far as I
know, we can't use that as an alternative.

However, I'd suspect that the FreeBSD kernel allows for some way to
tune the behavior of the syncer. If that's the case, we could do some
research into what settings are more appropriate for FreeBSD, and
recommend those in the docs. I don't run FreeBSD, however -- would
someone like to volunteer to take a look at this?

BTW Curtis, did you happen to check whether this behavior has been
changed in FreeBSD 5.0?

> Also, on a side note, IIRC, linux kernel 2.5.x has a new priority
> elevator which is said to be MUCH better as saturating disks than ever
> before.

Yeah, there are lots of new & interesting features for database
systems in the new kernel -- I'm looking forward to when 2.6 is widely
deployed...

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Where to call SetQuerySnapshot
Next
From: Joe Conway
Date:
Subject: Re: Where to call SetQuerySnapshot