Skip site navigation (1) Skip section navigation (2)

Re: TRUNCATE veeeery slow compared to DELETE in 7.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hartmut Raschick <hartmut(dot)raschick(at)ke-elektronik(dot)de>
Cc: pgsql-performance(at)postgresql(dot)org, Rod Taylor <pg(at)rbt(dot)ca>
Subject: Re: TRUNCATE veeeery slow compared to DELETE in 7.4
Date: 2003-12-15 18:21:47
Message-ID: 13898.1071512507@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Hartmut Raschick <hartmut(dot)raschick(at)ke-elektronik(dot)de> writes:
> [ TRUNCATE is much slower in 7.4 than in 7.3 ]

After looking into this, I think this is because when Rod Taylor
reimplemented TRUNCATE to make it transaction-safe, he essentially
turned it into a variant of CLUSTER.  It is slow because it is creating
and deleting dummy tables and indexes.  I think this is not really
necessary and it could be done better while still being
transaction-safe.  All we really need is to create a new empty table
file, update the table's pg_class row with the new relfilenode, mark
the old file for deletion, and then run REINDEX TABLE (which will
perform similar shenanigans with the indexes).

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Jeremy HefnerDate: 2003-12-15 22:54:35
Subject: unsubscribe
Previous:From: Tom LaneDate: 2003-12-15 18:05:51
Subject: Re: Index problem or function problem?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group