TRUNCATE veeeery slow compared to DELETE in 7.4

Поиск
Список
Период
Сортировка
От Hartmut Raschick
Тема TRUNCATE veeeery slow compared to DELETE in 7.4
Дата
Msg-id 3FD484B6.EF39A92F@ke-elektronik.de
обсуждение исходный текст
Ответы Re: TRUNCATE veeeery slow compared to DELETE in 7.4  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
has anyone else noticed a huge difference in "DELETE TABLE <lol>"
vs. "TRUNCATE <lol>" 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.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)

lovely, innit?

settings in 7.4 (wal, shm...) are as for 7.3.x unless dead or (in their
7.4 default version) even higher.

glimpsing at the quantify output (of the truncate version) it looks
as if this is "for (i = 0; i < all; i++)" whereas (from exec. time)
delete does "\rm -rf"

is this a pay-off for autocommit gone away?
a conspiracy?
...what am i saying...

we are using TRUNCATE btw, because someone once noted that this was
"good style", saying: "yes, i want to empty the whole thing", not:
"oops! forgot the where-clause, sorry for your table!"

well, enlight me, please!

P.S.: Grammarians dispute - and the case is still before the courts.
        - Horace, Epistles (Ars Poetica)

--
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.raschick@ke-elektronik.de
http://www.ke-elektronik.de

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ivar Zarans
Дата:
Сообщение: Slow UPDATE, INSERT OK
Следующее
От: Murthy Kambhampaty
Дата:
Сообщение: Re: [linux-lvm] RE: [ADMIN] backup/restore - another