Re: TRUNCATE veeeery slow compared to DELETE in 7.4

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, 20000 pieces of modelled hw, so there's one table
w/20000 entries, each model has a special table (per type), too;
so, entries over all of them sum up to 20000; not all types are
present.
plus: some types (w/not many instances) have "very special" tables,
too, these sometimes w/lots of columns 500-1600...

alone on a sun fire-280 w/2 U-IIIi cpu's (well, only need one...):
all the time of the test, no vacuum anything was performed,
thus - by the book - making things worse... for the DELETE case.

7.4:
----
"full" database:
TRUNCATE: 0.03u 0.03s 1:21.40 0.0%
DELETE: 0.05u 0.01s 0:04.46 1.3%

empty database:
TRUNCATE:0.02u 0.05s 1:21.00 0.0%
DELETE: 0.04u 0.04s 0:01.32 6.0%

now for 7.3.4 database server (same machine, of cause):
--------------
"full" database:
TRUNCATE: 0.04u 0.04s 0:03.79 2.1%
DELETE: 0.03u 0.03s 0:06.51 0.9%

empty database:
TRUNCATE: 0.04u 0.05s 0:01.51 5.9%
DELETE: 0.01u 0.02s 0:01.00 3.0%

what can i say...
...please find the attached configs.

i reeeeally don't think this can be explained by table/index
complexity, it's the _same_ schema and contents for both cases,
they both were started w/createdb, they both were filled the same
way (by our server prog), there was no vacuum nowhere, test execution
order was the same in both cases.

P.S.: Mon pessimisme va jusqu'à suspecter la sincérité des pessimistes.
- Jean Rostand (1894-1977), Journal d'un caractère, 1931

--
Hartmut "Hardy" Raschick / Dept. t2
ke Kommunikations-Elektronik GmbH
Wohlenberstr. 3, 30179 Hannover
Phone: ++49 (0)511 6747-564
Fax: ++49 (0)511 6747-340
e-Mail: hartmut(dot)raschick(at)ke-elektronik(dot)de
http://www.ke-elektronik.de