I wrote:
> > The REAL issue and the one that will greatly affect total system
> > throughput is that of contention on the file locks. Since
> fsynch needs to
> > obtain a write lock on the file descriptor, as does the write
> calls which
> > originate from XLogWrite as the writes are written to the disk, other
> > back-ends will block while another transaction is committing if the
> > log cache fills to the point where their XLogInsert results in a
> > XLogWrite call to flush the log cache.
tom lane wrote:
> But that's exactly *why* we have a log cache: to ensure we can buffer a
> reasonable amount of log data between XLogFlush calls. If the above
> scenario is really causing a problem, doesn't that just mean you need
> to increase wal_buffers?
Well, in cases where there are a lot of small transactions the contention
will not be on the XLogWrite calls from caches getting full but from
XLogWrite calls from transaction commits which will happen very frequently.
I think this will have a detrimental effect on very high update frequency
performance.
So while larger WAL caches will help in the case of cache flushing because
of its being full I don't think it will make any difference for the
potentially
more common case of transaction commits.
- Curtis
