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

Re: Async Commit, v21 (now: v22)

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Async Commit, v21 (now: v22)
Date: 2007-07-24 14:02:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, 24 Jul 2007, Gregory Stark wrote:

> 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.

Might there be some advantage in high-throughput/multi-[cpu|core] 
situations due to improved ability to keep that code in a single 
processor?  CPU cache issues are turning into scalability bottlenecks in 
so many designs I came across lately.  A distinct walwriter might be more 
likely to be (or even be explicitly) bound to a processor and stay there 
than when the code executes on any random backend.  The obvious flip side 
is that increased moving of data between processors more often may balance 
or even negate any potential improvement there.

More on the system tuning side, I know I've found that the background 
writer is a separate process enormously helpful because of how it allows 
monitoring the activity level of just it relative to the whole.  There are 
enough WAL-bound systems out there (particularly when there's no caching 
disk controller) that I could see similar value to being able to watch a 
distinct walwriter.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-07-24 14:10:11
Subject: Re: Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)
Previous:From: Tom LaneDate: 2007-07-24 14:01:07
Subject: Re: Async Commit, v21 (now: v22)

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