Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id EAE6F9FB747 for ; Thu, 12 Jul 2007 04:37:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 91584-04 for ; Thu, 12 Jul 2007 04:37:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from smtp.vodafone.nl (smtp-out.vizzavi.nl [195.232.199.126]) by postgresql.org (Postfix) with ESMTP id CB3409FB5AE for ; Thu, 12 Jul 2007 04:37:46 -0300 (ADT) Received: from conversion-daemon.vfnlw44s.vfnl.dc-ratingen.de by vfnlw44s.vfnl.dc-ratingen.de (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL2005012G9DE00@vfnlw44s.vfnl.dc-ratingen.de> (original mail from postgres@microbizz.nl) for pgsql-performance@postgresql.org; Thu, 12 Jul 2007 09:37:36 +0200 (MEST) Received: from [212.56.242.41] by vfnlw44s.vfnl.dc-ratingen.de (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JL200L012IHP550@vfnlw44s.vfnl.dc-ratingen.de> for pgsql-performance@postgresql.org; Thu, 12 Jul 2007 09:37:35 +0200 (MEST) Date: Thu, 12 Jul 2007 09:37:40 +0200 From: Adriaan van Os Subject: Re: TRUNCATE TABLE In-reply-to: <3561.1184190885@sss.pgh.pa.us> To: pgsql-performance@postgresql.org Message-id: <4695DA44.2060000@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> <3561.1184190885@sss.pgh.pa.us> User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/133 X-Sequence-Number: 25817 Gregory Stark wrote: > That's strange. Deleting should be the *quickest* operation in Postgres. Do > you perchance have foreign key references referencing this table? No. > Do you have any triggers? No. Tom Lane wrote: > Adriaan van Os writes: >> Surprisingly, one of the bottlenecks is TRUNCATE TABLE and that >> command is really slow as compared to other operations. > > When you don't quantify that statement at all, it's hard to make an > intelligent comment on it, but TRUNCATE per se shouldn't be slow. > Are you sure you are not measuring a delay to obtain exclusive lock > on the table before it can be truncated (ie, waiting for other > transactions to finish with it)? During the tests, there is only one connection to the database server. No other transactions are running. > When you don't quantify that statement at all, it's hard to make an > intelligent comment on it, but TRUNCATE per se shouldn't be slow. Below are some timings, in milliseconds. > TRUNCATE TABLE my_temporary_table > COPY my_temporary_table ... FROM STDIN BINARY > do_something The temporary table has one INT4 field and no indices. Numrows TRUNCATE (ms) COPY (ms) SELECT (ms) 5122 80,6 16,1 51,2 3910 79,5 12,9 39,9 2745 90,4 10,7 32,4 1568 99,5 7,6 24,7 398 161,1 4,0 22,1 200 79,5 3,3 22,0 200 87,9 3,1 22,0 222368 4943,5 728,6 7659,5 222368 1685,7 512,2 2883,1 Note how fast the COPY is (which is nice). The SELECT statement uses the temporary table. Regards, Adriaan van Os