| От | Tom Lane |
|---|---|
| Тема | Re: TRUNCATE veeeery slow compared to DELETE in 7.4 |
| Дата | |
| Msg-id | 13898.1071512507@sss.pgh.pa.us обсуждение |
| Ответ на | Re: TRUNCATE veeeery slow compared to DELETE in 7.4 (Hartmut Raschick <hartmut.raschick@ke-elektronik.de>) |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера