Re: TRUNCATE veeeery slow compared to DELETE in 7.4 - Mailing list pgsql-performance

From Tom Lane
Subject Re: TRUNCATE veeeery slow compared to DELETE in 7.4
Date
Msg-id 8000.1071086054@sss.pgh.pa.us
Whole thread Raw
In response to Re: TRUNCATE veeeery slow compared to DELETE in 7.4  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
Josh Berkus <josh@agliodbs.com> writes:
> Incidentally, I believe that TRUNCATE has always been slightly slower than
> DROP TABLE.

Well, it would be: it has to delete the original files and then create
new ones.  I imagine the time to create new, empty indexes is the bulk
of the time Hartmut is measuring.  (Remember that an "empty" index has
at least one page in it, the metadata page, for all of our index types,
so there is some actual I/O involved to do this.)

It does not bother me that TRUNCATE takes nonzero time; it's intended
to be used in situations where DELETE would take huge amounts of time
(especially after you factor in the subsequent VACUUM activity).
The fact that DELETE takes near-zero time on a zero-length table is
not very relevant.

            regards, tom lane

pgsql-performance by date:

Previous
From: nbarraza@uolsinectis.com.ar
Date:
Subject: ...
Next
From: Stephan Szabo
Date:
Subject: Re: