Re: Async Commit, v21 (now: v22) - Mailing list pgsql-patches

From Tom Lane
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 8686.1185285667@sss.pgh.pa.us
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Async Commit, v21 (now: v22)  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Async Commit, v21 (now: v22)  (Gregory Stark <stark@enterprisedb.com>)
Re: Async Commit, v21 (now: v22)  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-patches
Gregory Stark <stark@enterprisedb.com> 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.

            regards, tom lane

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: msvc const warnings
Next
From: Magnus Hagander
Date:
Subject: Re: plperl warnings on win32