explainsgml修正

Author: ChenHuajun

postgresql/doc/src/sgml/ref/explain.sgml

@@ -130,7 +130,7 @@ ____________________________________________________________________________-->
   </para>
 ____________________________________________________________________________-->
   <para>
-   显示中最重要的部分是估计出的语句执行代价，它是计划器对于该语句要运行多久的猜测（以任意的代价单位度量，但是习惯上表示取磁盘页面的次数）。事实上会显示两个数字：在第一行能被返回前的启动代价，以及返回所有行的总代价。对于大部分查询来说总代价是最重要的，但是在一些情景中（如<literal>EXISTS</literal>中的子查询），计划器将选择更小的启动代价来代替最小的总代价（因为因为执行器将在得到一行后停止）。此外，如果你用一个<literal>LIMIT</literal>子句限制返回行的数量，计划器会在终端代价之间做出适当的插值来估计到底哪个计划是真正代价最低的。
+   显示中最重要的部分是估计出的语句执行代价，它是计划器对于该语句要运行多久的猜测（以任意的代价单位度量，但是习惯上表示取磁盘页面的次数）。事实上会显示两个数字：在第一行能被返回前的启动代价，以及返回所有行的总代价。对于大部分查询来说总代价是最重要的，但是在一些情景中（如<literal>EXISTS</literal>中的子查询），计划器将选择更小的启动代价来代替最小的总代价（因为执行器将在得到一行后停止）。此外，如果你用一个<literal>LIMIT</literal>子句限制返回行的数量，计划器会在终端代价之间做出适当的插值来估计到底哪个计划是真正代价最低的。
   </para>
 
 <!--==========================orignal english content==========================
@@ -468,9 +468,9 @@ ____________________________________________________________________________-->
   </para>
 ____________________________________________________________________________-->
   <para>
-   为了执行计划中每个结点的运行时间开销，当前的In order to measure the run-time cost of each node in the execution
-   plan, the current implementation of <command>EXPLAIN
-   ANALYZE</command>实现为查询执行增加了 profiling overhead 。这样，在一个查询上运行<command>EXPLAIN ANALYZE</command>有时候比正常执行该查询要慢很多。开销的量取决于该查询的性质，以及使用的平台。最坏的情况会发生在那些自身执行时间很短的结点上，以及在那些具有相对较慢的有关时间的操作系统调用的机器上。
+   为了度量执行计划中每个节点的运行时成本，当前的<command>EXPLAIN ANALYZE</command>的当前实现为查询执行增加了性能分析开销。
+   这样，在一个查询上运行<command>EXPLAIN ANALYZE</command>有时候比正常执行该查询要慢很多。
+   开销的量取决于该查询的性质，以及使用的平台。最坏的情况会发生在那些自身执行时间很短的结点上，以及在那些具有相对较慢的有关时间的操作系统调用的机器上。
   </para>
  </refsect1>