Re: TRUNCATE TABLE

Список
Период
Сортировка
От Tom Lane
Тема Re: TRUNCATE TABLE
Дата
Msg-id 661.1186425974@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: TRUNCATE TABLE  (Decibel!)
Список 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, )
Decibel! <> writes:
> Interesting. I'm guessing that ext3 has to sync out the entire journal
> up to the point in time that fsync() is called, regardless of what
> files/information the journal contains. Fortunately I think it's common
> knowledge to mount PostgreSQL filesystems with data=3Dwriteback, which
> hopefully eliminates much of that bottleneck... but if you don't do
> noatime you're probably still spewing a lot out to the drive.

FWIW, I tried to test the above by running Pavel's script on an ext3
partition mounted noatime,data=writeback.  This didn't seem to make any
difference --- still very large deviations in the time to do a TRUNCATE.
However the problem seems harder to reproduce now than it was three weeks
ago.  In the meantime I installed a 2.6.22-based kernel instead of the
2.6.20 one that Fedora was using before; I wonder whether the kernel
guys tweaked something related ...

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
Следующее
От: Mark Makarowsky
Дата:
Сообщение: Update table performance