postgres 8.3 / Ubuntu Karmic / 32-bit (in virtualbox):
duration: 76.534 ms statement: truncate audit.users cascade duration: 0.952 ms statement: delete from audit.users
postgres 8.4 / Ubuntu lucid / 64-bit (native, on the machine hosting the karmic virtualbox):
duration: 1469.271 ms statement: truncate audit.users cascade duration: 0.988 ms statement: delete from audit.users
So the DELETE statements are pretty much equivalent, but TRUNCATE takes 20x longer on one platform than the other. EXPLAIN doesn’t seem to work on TRUNCATE. How do I find out what’s taking so long?
Edited to add:
The above samples were taken when there was another idle connection open to the database, but no open transactions or other activity. I use TRUNCATE in the tearDown method of some automated tests, which is where I noticed the speed difference between platforms.
The way TRUNCATE works in PostgreSQL, it’s very sensitive to how fast your filesystem can delete blocks, as well as whether it correctly honors the fsync system call when you write to flush the write cache out. My guess is that you have different filesystem setups on the two systems. For example, if the Lucid install is using ext4 and the Karmic one ext3, this is unsurprising behavior. Newer kernels will correctly turn fsync calls into disk cache flushing via write barriers; older ones let the drives lie to them about things being written. This is a good thing in terms of keeping the database writes safe during a crash, but performance drops a lot when the kernel does the right thing from a reliability perspective.