От: Adriaan van Os
Тема: Re: TRUNCATE TABLE
Дата: ,
Msg-id: 4695DA44.2060000@microbizz.nl
(см: обсуждение, исходный текст)
Ответ на: Re: TRUNCATE TABLE  (Tom Lane)
Ответы: Re: TRUNCATE TABLE  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

TRUNCATE TABLE  (Adriaan van Os, )
 Re: TRUNCATE TABLE  (Tom Lane, )
  Re: TRUNCATE TABLE  (Adriaan van Os, )
   Re: TRUNCATE TABLE  (Tom Lane, )
 Re: TRUNCATE TABLE  (Gregory Stark, )
  Re: TRUNCATE TABLE  (Adriaan van Os, )
   Re: TRUNCATE TABLE  (Gregory Stark, )
   Re: TRUNCATE TABLE  (Jean-Max Reymond, )
    Re: TRUNCATE TABLE  ("Thomas Samson", )
   Re: TRUNCATE TABLE  (Michael Stone, )
    Re: TRUNCATE TABLE  (Tom Lane, )
     Re: TRUNCATE TABLE  (Adriaan van Os, )
      Re: TRUNCATE TABLE  ("Steinar H. Gunderson", )
      Re: TRUNCATE TABLE  (Tom Lane, )
       Re: TRUNCATE TABLE  ("Jim C. Nasby", )
       Re: TRUNCATE TABLE  (Alvaro Herrera, )
        Re: TRUNCATE TABLE  ("Pavel Stehule", )
         Re: TRUNCATE TABLE  ("Jim C. Nasby", )
          Re: TRUNCATE TABLE  (Tom Lane, )
           Re: TRUNCATE TABLE  (Adriaan van Os, )
           Re: TRUNCATE TABLE  (Adriaan van Os, )
            Re: TRUNCATE TABLE  (Alvaro Herrera, )
           Re: TRUNCATE TABLE  ("Kevin Grittner", )
            Re: TRUNCATE TABLE  (Adriaan van Os, )
             Re: TRUNCATE TABLE  (Decibel!, )
              Re: TRUNCATE TABLE  (Tom Lane, )
       Re: TRUNCATE TABLE  (Adriaan van Os, )

Gregory Stark wrote:
> That's strange. Deleting should be the *quickest* operation in Postgres. Do
> you perchance have foreign key references referencing this table?

No.

> Do you have any triggers?

No.

Tom Lane wrote:
> Adriaan van Os <> writes:
>> Surprisingly, one of the bottlenecks is TRUNCATE TABLE and that
>> command is really slow as compared to other operations.
>
> When you don't quantify that statement at all, it's hard to make an
> intelligent comment on it, but TRUNCATE per se shouldn't be slow.
> Are you sure you are not measuring a delay to obtain exclusive lock
> on the table before it can be truncated (ie, waiting for other
> transactions to finish with it)?

During the tests, there is only one connection to the database server. No other transactions are
running.

> When you don't quantify that statement at all, it's hard to make an
> intelligent comment on it, but TRUNCATE per se shouldn't be slow.

Below are some timings, in milliseconds.

> TRUNCATE TABLE my_temporary_table
> COPY my_temporary_table ... FROM STDIN BINARY
> do_something

The temporary table has one INT4 field and no indices.

Numrows        TRUNCATE (ms)            COPY (ms)        SELECT (ms)
   5122                  80,6                    16,1                51,2
   3910                  79,5                    12,9                39,9
   2745                  90,4                    10,7                32,4
   1568                  99,5                     7,6                24,7
    398                 161,1                     4,0                22,1
    200                  79,5                     3,3                22,0
    200                  87,9                      3,1                22,0
222368                 4943,5                 728,6            7659,5
222368                1685,7                 512,2            2883,1

Note how fast the COPY is (which is nice). The SELECT statement uses the temporary table.

Regards,

Adriaan van Os



В списке pgsql-performance по дате сообщения:

От: Heikki Linnakangas
Дата:
Сообщение: Re: one column from huge view
От: Tom Lane
Дата:
Сообщение: Re: pg_restore causes 100