Alfred Perlstein <bright@wintelcom.net> writes:
>> couldn't the syncer process cache opened files? is there any problem I
>> didn't consider ?
> 1) IPC latency, the amount of time it takes to call fsync will
> increase by at least two context switches.
> 2) a working set (number of files needed to be fsync'd) that
> is larger than the amount of files you wish to keep open.
These days we're really only interested in fsync'ing the current WAL
log file, so working set doesn't seem like a problem anymore. However
context-switch latency is likely to be a big problem. One thing we'd
definitely need before considering this is to replace the existing
spinlock mechanism with something more efficient.
Vadim has designed the WAL stuff in such a way that a separate
writer/syncer process would be easy to add; in fact it's almost that way
already, in that any backend can write or sync data that's been added
to the queue by any other backend. The question is whether it'd
actually buy anything to have another process. Good stuff to experiment
with for 7.2.
regards, tom lane