Hartmut Raschick <[EMAIL PROTECTED]> 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
for the clearer understanding: this is NOT about TRUNCATE being
slow "as such" vs. DELETE, but about a change in the order of
a (...) magnitude from 7.3.4 to 7.4...
here's some more info, plus test results w/a "full" db:
300 tables, 2 pieces of modelled hw, so there's one table
w/2 entrie
Josh Berkus <[EMAIL PROTECTED]> 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 m
Hartmut,
> DELETE:
> 1) 0.03u 0.04s 0:02.46 2.8% (already empty)
> 2) 0.05u 0.06s 0:01.19 9.2% (already empty)
>
> TRUNCATE:
> 1) 0.10u 0.06s 6:58.66 0.0% (already empty, compile runnig simult.)
> 2) 0.10u 0.02s 2:51.71 0.0% (already empty)
How about some times for a full table?
Incidentally, I
has anyone else noticed a huge difference in "DELETE TABLE "
vs. "TRUNCATE " starting w/postgres 7.4?
putting aside details (num rows, indexes): ca. 300 tables
(already empty if desired...) ALL to be emptied (via batch file).
here's a small "time pgsql -f kill_all" output:
DELETE:
1) 0.03u 0.0
