Skip site navigation (1) Skip section navigation (2)

Re: Async Commit, v21 (now: v22)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-patches(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Subject: Re: Async Commit, v21 (now: v22)
Date: 2007-07-24 08:10:47
Message-ID: 873azeql14.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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


In response to

Responses

pgsql-patches by date

Next:From: Florian WeimerDate: 2007-07-24 08:51:03
Subject: Re: Async Commit, v21 (now: v22)
Previous:From: Neil ConwayDate: 2007-07-24 06:57:04
Subject: RETURN QUERY

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group