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 13898.1071512507@sss.pgh.pa.us
Whole thread Raw
In response to Re: TRUNCATE veeeery slow compared to DELETE in 7.4  (Hartmut Raschick <hartmut.raschick@ke-elektronik.de>)
List pgsql-performance
Hartmut Raschick <hartmut.raschick@ke-elektronik.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Index problem or function problem?
Next
From: Claudia D'amato
Date:
Subject: Postgres respond after toomany times to a query view