On Fri, Oct 29, 2010 at 11:56 AM, Aidan Van Dyk <aidan@xxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
