To: Decibel! <decibel@decibel.org>
cc: Adriaan van Os <postgres@microbizz.nl>, pgsql-performance@postgresql.org
Subject: Re: TRUNCATE TABLE 
In-reply-to: <20070806054853.GK25704@nasby.net> 
References: <46972DFA.9000900@microbizz.nl> <20070713124435.GL31358@mathom.us>
	<21495.1184337630@sss.pgh.pa.us> <4697A58E.8060904@microbizz.nl>
	<23092.1184344246@sss.pgh.pa.us>
	<20070713173501.GD12109@alvh.no-ip.org>
	<162867790707131212g17cbc5a9q5d098dbf01c8e502@mail.gmail.com>
	<25418.1184631498@sss.pgh.pa.us>
	<46B050B8.EE98.0025.0@wicourts.gov> <46B4F213.3000203@microbizz.nl>
	<20070806054853.GK25704@nasby.net>
Comments: In-reply-to Decibel! <decibel@decibel.org>
	message dated "Mon, 06 Aug 2007 00:48:54 -0500"
Date: Mon, 06 Aug 2007 14:46:14 -0400
Message-ID: <661.1186425974@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Decibel! <decibel@decibel.org> writes:
> Interesting. I'm guessing that ext3 has to sync out the entire journal
> up to the point in time that fsync() is called, regardless of what
> files/information the journal contains. Fortunately I think it's common
> knowledge to mount PostgreSQL filesystems with data=3Dwriteback, which
> hopefully eliminates much of that bottleneck... but if you don't do
> noatime you're probably still spewing a lot out to the drive.

FWIW, I tried to test the above by running Pavel's script on an ext3
partition mounted noatime,data=writeback.  This didn't seem to make any
difference --- still very large deviations in the time to do a TRUNCATE.
However the problem seems harder to reproduce now than it was three weeks
ago.  In the meantime I installed a 2.6.22-based kernel instead of the
2.6.20 one that Fedora was using before; I wonder whether the kernel
guys tweaked something related ...

			regards, tom lane