| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| 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 14:01:07 |
| Message-ID: | 8686.1185285667@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2007-07-24 14:02:34 | Re: Async Commit, v21 (now: v22) |
| Previous Message | Magnus Hagander | 2007-07-24 13:59:15 | Re: plperl warnings on win32 |