Message-ID: <47A8862A.1060205@archonet.com>
Date: Tue, 05 Feb 2008 15:52:10 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Matthew <matthew@flymine.org>
CC: pgsql-performance@postgresql.org
Subject: Re: Benchmark Data requested
References: <1202150236.4252.521.camel@ebony.site>
	<Pine.GSO.4.64.0802041500460.799@westnet.com>
	<47A797E5.4000507@sun.com>
	<200802051506.51581.dfontaine@hi-media.com>
	<1202221496.4252.680.camel@ebony.site>
	<47A87618.1090203@archonet.com>
	<1202223268.4252.707.camel@ebony.site>
	<Pine.LNX.4.64.0802051523470.20402@aragorn.flymine.org>
In-Reply-To: <Pine.LNX.4.64.0802051523470.20402@aragorn.flymine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Matthew wrote:
> On Tue, 5 Feb 2008, Simon Riggs wrote:
>>> In the case of a bulk upload to an empty table (or partition?) could you
>>> not optimise the WAL away? That is, shouldn't the WAL basically be a
>>> simple transformation of the on-disk blocks? You'd have to explicitly
>>> sync the file(s) for the table/indexes of course, and you'd need some
>>> work-around for WAL shipping, but it might be worth it for you chaps
>>> with large imports.
>>
>> Only by locking the table, which serializes access, which then slows you
>> down or at least restricts other options. Plus if you use pg_loader then
>> you'll find only the first few rows optimized and all the rest not.
> 
> Why would you need to lock the table?

Because you're not really writing the WAL, which means you can't let 
anyone else get their data into any of the blocks you are writing into. 
You'd basically want to write the disk blocks then "attach" them in some 
way.

-- 
   Richard Huxton
   Archonet Ltd