Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Without async commits? Do we really want the walwriter doing the >> majority of the wal-flushing work for normal commits? It seems like >> that's not going to be any advantage over just having some random >> backend do the commit. > > Sure: the advantage is that the backends (ie, user query processing) > don't get blocked on fsync's. This is not really different from the > rationale for having the bgwriter. It's probably most useful for large > transactions, which up to now generally had to stop and flush the WAL > buffers every few pages worth of WAL output.
I wonder what it would take to offload the CRC calculation to the wal writer. And if that would then become a bottleneck, making it actually counterproductive. No, not in this release :). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster