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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
