Message-ID: <4E781EF8.3000400@ringerc.id.au>
Date: Tue, 20 Sep 2011 13:04:56 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: Jon Nelson <jnelson+pgsql@jamponi.net>
CC: pgsql-performance@postgresql.org
Subject: Re: Postgres INSERT performance and scalability
References: 
 <CAMhtkAb1F1SOyz1mzeeWaQehoqtzk29oLVVG=NzKEoGS9bPDNg@mail.gmail.com>
	<20110920005342.GO12765@tamriel.snowman.net>
	<CAKuK5J0-fEHVm_c_H6T6XMk9PQE6zDohBHqZ39CHu5Hz0kGC4g@mail.gmail.com>
In-Reply-To: 
 <CAKuK5J0-fEHVm_c_H6T6XMk9PQE6zDohBHqZ39CHu5Hz0kGC4g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 09/20/2011 09:21 AM, Jon Nelson wrote:
> Isn't the WAL basically COW?

Nope, it's a lot more like a filesystem journal - though it includes all 
data, not just metadata like filesystem journals usually do.

Now, you could argue that PostgreSQL uses a copy-on-write like system to 
maintain row versions so that already-running statements (or 
SERIALIZABLE transactions) don't see data from the future and to 
maintain rollback data for uncommitted transactions. It's the *new* data 
that gets written to the WAL, though, not the old data.

(OK, if you have full_page_writes enabled you might get a mix of old and 
new data written to WAL, but that's an implementation detail).

--
Craig Ringer