From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Decibel! <decibel(at)decibel(dot)org> |
Cc: | Adriaan van Os <postgres(at)microbizz(dot)nl>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: TRUNCATE TABLE |
Date: | 2007-08-06 18:46:14 |
Message-ID: | 661.1186425974@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Decibel! <decibel(at)decibel(dot)org> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-08-06 19:47:22 | Re: Extreme slow select query 8.2.4 |
Previous Message | Ted Jordan | 2007-08-06 17:58:19 | Re: Default Performance between 8.0 and 8.1 |