On Tue, 2007-07-24 at 10:01 -0400, 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.
Let's measure things and set the defaults accordingly. > 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. That should be a reasonable gain from avoiding CPU/disk flip-flopping, but we are still CPU bound on COPY. Will measure. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
