"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> I wrote:
>> (BTW, in case you can't tell from the drift of my questions, I've
>> separated the patch into "add background wal writer" and "add async
>> commit", and am working on the first half.)
>
> I've committed the first half of that. Something that still needs
> investigation is what the default wal_writer_delay should be. I left
> it at 200ms as submitted, but in some crude testing here (just running
> the regression tests and strace'ing the walwriter) it seemed that I had
> to crank it down to 10ms before the walwriter was really doing the
> majority of the wal-flushing work.
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.
The only way the walwriter seems like an advantage is either with async
commits or with something like commit_delay and some extra logic in the
walwriter to aim for grouping together the maximum number of commits.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
