On Fri, Oct 29, 2010 at 11:56 AM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> 1) The pages you write to must be in the page cache, or your memcpy is
> going to fault them in. With a plain write, you don't need the
> over-written page in the cache.
I seem to remember a time many years ago when I got bitten by this
problem. The fact that our I/O is in 8K pages means this could be a
pretty severe hit, I think.
> 2) Now, instead of the torn-page problem being FS block/sector sized
> base, you can now actually have a possibly arbitrary amount of the
> block memory written when the kernel writes out the page. you
> *really* need full-page-writes.
Yeah.
> 3) The mmap overhead required for the kernel to setup the mappings is
> less than the repeated syscalls of a simple write().
You'd expect to save something from that; but on the other hand, at
least on 32-bit systems, there's a very limited number of 1GB files
that can be simultaneously mapped into one address space, and it's a
lot smaller than the number of file descriptors that you can have
open. Rumor has it that cutting down the number of fds that can stay
open simultaneously is pretty bad for performance, so cutting it down
to a number you can count on one hand (maybe one finger) would
probably be bad. Maybe on 64-bit it would be OK but it seems like an
awful lot of complexity for at most a minor savings (and a pretty bad
anti-savings if point #1 kicks in).
Anyway this is all totally off-topic...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company