Re: TRUNCATE TABLE

Список
Период
Сортировка
От Decibel!
Тема Re: TRUNCATE TABLE
Дата
Msg-id 20070806054853.GK25704@nasby.net
обсуждение исходный текст
Ответ на Re: TRUNCATE TABLE  (Adriaan van Os)
Ответы 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, )
On Sat, Aug 04, 2007 at 11:39:31PM +0200, Adriaan van Os wrote:
> Kevin Grittner wrote:
> >>>>On Mon, Jul 16, 2007 at  7:18 PM, in message
> >>>><>,
> >Tom Lane <> wrote:
> >>Somehow, autovac is doing something that makes the filesystem go nuts
> >>every so often, and take an astonishingly long time to create an empty
> >>file.  But autovac itself doesn't create or delete any files, so what's
> >>up here?
> >
> >Have you ruled out checkpoints as the culprit?
>
> That's a good question. I will do some more tests, but I also suspect fsync
> "cascading"
> <http://www.uwsg.iu.edu/hypermail/linux/kernel/0708.0/1435.html>.

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=writeback, 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.
--
Decibel!, aka Jim Nasby                        
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Вложения

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

Предыдущее
От: "Sven Clement"
Дата:
Сообщение: Re: Performance problems with large telemetric datasets on 7.4.2
Следующее
От: Henrik Zagerholm
Дата:
Сообщение: Planner making wrong decisions 8.2.4. Insane cost calculations.