On Mon, Aug 16, 2010 at 04:54:19PM -0400, Greg Smith wrote: > Andres Freund wrote: > >A new checkpointing logic + a new syncing logic > >(prepare_fsync() earlier and then fsync() later) would be a nice > >thing. Do you plan to work on that? > The background writer already caches fsync calls into a queue, so > the prepare step you're thinking needs to be there is already. The > problem is that the actual fsync calls happen in a tight loop. That > we're busy fixing. That doesn't help that much on many systems with a somewhat deep queue. An fsync() equals a barrier so it has the effect of stopping reordering around it - especially on systems with larger multi-disk arrays thats pretty expensive. You can achieve surprising speedups, at least in my experience, by forcing the kernel to start writing out pages *without enforcing barriers* first and then later enforce a barrier to be sure its actually written out. Which, in a simplified case, turns the earlier needed multiple barriers into a single one (in practise you want to call fsync() anyway, but thats not a big problem if its already written out).
Andres -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
