To: Greg Smith <gsmith@gregsmith.com>
cc: PostgreSQL-patches <pgsql-patches@postgresql.org>
Subject: Re: Maintaining cluster order on insert 
In-reply-to: <Pine.GSO.4.64.0707100815400.22343@westnet.com> 
References: <200705152223.l4FMNJa17969@momjian.us>
	<464A33AB.1050401@enterprisedb.com>
	<20070516003810.GI20707@nasby.net>
	<464B15EF.4000808@enterprisedb.com>
	<c2d9e70e0705172153g3207adb6kd4abdfdf3a9215ff@mail.gmail.com>
	<464D96D6.1030608@enterprisedb.com> <457.1184023772@sss.pgh.pa.us>
	<Pine.GSO.4.64.0707100815400.22343@westnet.com>
Comments: In-reply-to Greg Smith <gsmith@gregsmith.com>
	message dated "Tue, 10 Jul 2007 08:52:54 -0400"
Date: Tue, 10 Jul 2007 10:34:39 -0400
Message-ID: <19371.1184078079@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Greg Smith <gsmith@gregsmith.com> writes:
> On Mon, 9 Jul 2007, Tom Lane wrote:
>> The hardware is just a Dell x86_64 workstation with crappy IDE disk, so 
>> maybe things would look better elsewhere, but it's all I have to work 
>> with.

> Do you have write-caching turned off on the drive so INSERTs are being 
> rate-limited by WAL syncs?  Trying to characterize the class of setup 
> you're using.

It's just desktop-grade junk :-(.  Feel free to repeat the test on
something more serious.

> The part that seemed curious to me about your results in the unpatched 
> version is why the first INSERT takes 2.4 seconds, while the second takes 
> 12.2 then later ones settle from 17-23 s.  I could understand the 12-23 
> variation, but that the first one fires off in 2.4 seems kind of fishy; 

The test seemed to be mostly I/O bound according to vmstat.  I supposed
that it was fast up until the kernel's available space was full of dirty
pages, and then subsequent writes would be constrained by actual disk
write bandwidth.  Anyway the numbers seemed relatively consistent after
the setup and first test cycle, so I think the part I was actually
trying to draw conclusions from was probably real enough.

			regards, tom lane