Re: TRUNCATE veeeery slow compared to DELETE in 7.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Hartmut Raschick <hartmut(dot)raschick(at)ke-elektronik(dot)de>, pgsql-performance(at)postgresql(dot)org
Subject: Re: TRUNCATE veeeery slow compared to DELETE in 7.4
Date: 2003-12-10 19:54:14
Message-ID: 8000.1071086054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stephan Szabo 2003-12-10 20:35:05 Re:
Previous Message nbarraza 2003-12-10 19:29:58