Date: Wed, 18 Jul 2007 09:36:45 +0200
From: Adriaan van Os <postgres@microbizz.nl>
Subject: Re: TRUNCATE TABLE
In-reply-to: <25418.1184631498@sss.pgh.pa.us>
To: pgsql-performance@postgresql.org
Message-id: <469DC30D.3060603@microbizz.nl>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <46953949.3030201@microbizz.nl>
 <87ps2ypox3.fsf@oxford.xeocode.com>
	<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>
	<20070716213944.GA39272@nasby.net> <25418.1184631498@sss.pgh.pa.us>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516)

Tom Lane wrote:

> Thus the timing issue (at least as exhibited by this script) has nothing
> whatever to do with the time to delete a file, but with the time to
> create one.  Since the part of DROP being timed has probably got no I/O
> involved at all (the tuples being touched are almost surely still in
> shared buffers), it's unsurprising that it is consistently fast.

In my original profiling, CREATE TEMPORARY TABLE/DROP TABLE wasn't much faster than TRUNCATE TABLE. 
When I try it again now, I see that DROP TABLE is consistently fast, while the timings of CREATE 
TEMPORARY TABLE vary as much as those of TRUNCATE TABLE. Your observations on the time needed to 
open a file confirm that, I think.

In my test databases, autovacuum is off.

Regards,

Adriaan van Os