sql - 如何调试 postgresql TRUNCATE 时间的差异？

Question

postgres 8.3/Ubuntu Karmic/32 位(在 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 位( native ，在托管 karmic virtualbox 的计算机上):

  duration: 1469.271 ms  statement: truncate audit.users cascade  duration: 0.988 ms  statement: delete from audit.users

因此，DELETE 语句几乎是等效的，但 TRUNCATE 在一个平台上花费的时间比另一个平台长 20 倍。 EXPLAIN 似乎不适用于 TRUNCATE。我怎样才能知道是什么花了这么长时间？

编辑添加:

以上示例是在有另一个空闲连接打开到数据库但没有打开的事务或其他事件时获取的。我在一些自动化测试的 tearDown 方法中使用 TRUNCATE，这是我注意到平台之间速度差异的地方。

Answer 1

TRUNCATE 在 PostgreSQL 中的工作方式，对文件系统删除 block 的速度以及当您写入以刷新写入缓存时是否正确执行 fsync 系统调用非常敏感。我的猜测是您在两个系统上有不同的文件系统设置。例如，如果 Lucid 安装使用 ext4 而 Karmic one ext3，则这种行为并不奇怪。较新的内核将通过写屏障正确地将 fsync 调用转换为磁盘缓存刷新；年长的人让驱动器对他们正在写入的内容撒谎。就在崩溃期间保持数据库写入安全而言，这是一件好事，但当内核从可靠性角度做正确的事情时，性能会下降很多。