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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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