《PostGreSQL9.0性能调校》， 翻译不是一般的滥！

lsstarboy

作者：吴骅　周娟　王学昌

怀着很大的期望买了这本，结果发现上当了！

作者在咱坛子里吗？我要索赔！比机器翻译强不了多少，不看还懂一些，看了部分彻底不懂了！雇用大学生当短工也不至于滥到这种程度。

此书很有收藏价值，可以作为翻译滥的标准，以后再说“翻译水平简直要赶上那本书了”，就是指这本

给大家奉献一段：

早期的IDE硬盘FLUSH CACHE技术，但最大只支持137GB窠。ATA-6特别增加了对大容量硬盘的支持，同时引入了强制性FLUSH CACHE EXT调用。这是发送给一个文件系统（以及数据库）所需要的驱动器用于当前写缓存刷新的命令。市面上任意一块磁盘都可以很容易处理这些，早些年部分IDE硬盘和少部分早期的SATA则不然。现在，如果用户需要刷新缓存，则硬盘可以很可靠地完成。
支持原生命令队列（NCP,Native Command Queuing)的SATA硬盘也可以处理FUA。需要注意的是Linux下的NCQ的支持是以libata驱动作为Linux内核2.6.19中的一部分，但是一些发行版（例如RadHat）已经将这个变更移植到早期发布的内核里。用户可以将SATA硬盘配置为sda使用libata，或者运行如下命令。
$ dmesg | grep libata
实际在系统调用时会有一些不同，但有效的行为是任何一个先进的驱动器都会支持屏障运行所需的缓存刷新功能。Linux对硬盘的测试是确认用户启用屏障功能，所以如果功能已启用，那么它们就可以直接进入工作。

很难找到这样一个CPU基准评测，这个评测比仅使用灵气库执行处理器型测试得到更多比较有挖根生的数据库性能。……插入的时间以及花费在对每个值进行计数上的时间是比较有意义的数值，后者当中也包含了某些与PostgreSQL用于去追踪事务可见性信息的更新提示位信息值相关的CPU/内存密集型的操作。

lsstarboy

在  ulovko  分享的链接上，找到了原文，要不是我英文只是初中水平，坚决不看这本翻译的书：

Early IDE drives implemented a FLUSH CACHE call and were limited to 137 GB
in size. The ATA-6 specification added support for larger drives at the same time it
introduced the now mandatory FLUSH CACHE EXT call. That's the command you
send to a drive that does what filesystems (and the database) want for write cache
flushing currently. Any SATA drive in the market now will handle this call just fine;
some IDE and the occasional rare early SATA drives available many years ago did
not. Today, if you tell a drive to flush its cache out, you can expect it will do  
so reliably.
SATA drives that support Native Command Queuing also can handle FUA. Note
that support for NCQ in Linux was added as part of the switch to the libata driver in
kernel 2.6.19, but some distributions (such as RedHat) have back ported this change
to their version of the earlier kernels they ship. You can tell if you're using libata
either by noting that your SATA drives are named starting with sda, or by running:
$ dmesg | grep libata
The exact system calls used will differ a bit, but the effective behavior is that any
modern drive should support the cache flushing commands needed for the barriers
to work. And Linux tests the drives out to confirm that this is the case before letting
you enable barriers, so if they're on, they are expected to work.

It's rather hard to find a CPU benchmark that is more representative of  
database performance more useful than just using a database to do something
processor-intensive.

Both the insertion time and how long it takes to count each value are interesting
numbers. The latter also includes some CPU/memory-intensive work related
to updating the hint bit values PostgreSQL uses to track transaction visibility
information;

xjflyttp

（NCP,Native Command Queuing)

这是OCR + Google翻译的吧。。。。