* Tom Lane <tgl@sss.pgh.pa.us> [010316 08:16] wrote:
> 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.
What sort of problems are you seeing with the spinlock code?
> 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.
The delayed/coallecesed (sp?) fsync looked interesting.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
