...

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. =3DA0With 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. =A0The 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. =3DA0you
> *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. =A0 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. =A0Maybe 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...

--=3D20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--=3D20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance




--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company