Merge pull request #290 from ChenHuajun/master

PG12翻译explain.sgml，insert.sgml，perform.sgml，pgstatstatements.sgml，pgt…

Author: ChenHuajun

postgresql/doc/src/sgml/perform.sgml

@@ -1541,19 +1541,23 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
    <para>
-    Generally, the <command>EXPLAIN</command> output will display details for
-    every plan node which was generated by the query planner.  However, there
-    are cases where the executor is able to determine that certain nodes are
-    not required; currently, the only node type to support this is the
-    <literal>Append</literal> node.  This node type has the ability to discard
-    subnodes which it is able to determine won't contain any records required
-    by the query.  It is possible to determine that nodes have been removed in
-    this way by the presence of a "Subplans Removed" property in the
-    <command>EXPLAIN</command> output.
+    Normally, <command>EXPLAIN</command> will display every plan node
+    created by the planner.  However, there are cases where the executor
+    can determine that certain nodes need not be executed because they
+    cannot produce any rows, based on parameter values that were not
+    available at planning time.  (Currently this can only happen for child
+    nodes of an Append or MergeAppend node that is scanning a partitioned
+    table.)  When this happens, those plan nodes are omitted from
+    the <command>EXPLAIN</command> output and a <literal>Subplans
+    Removed: <replaceable>N</replaceable></literal> annotation appears
+    instead.
    </para>
 ____________________________________________________________________________-->
    <para>
-    通常，<command>EXPLAIN</command>输出将显示查询规划器生成的每个计划节点的详细情况。不过，有一些情况中执行器能够确定特定的节点不是必需的。当前，唯一支持这种行动的节点类型是<literal>Append</literal>节点。这种节点类型有能力丢弃掉确定不会产生查询所需记录的子节点。可以通过<command>EXPLAIN</command>输出中的“Subplans Removed”属性的存在确定已经被移除的节点。
+    通常，<command>EXPLAIN</command>将显示规划器生成的每个计划节点。
+    但是，在某些情况下，执行器可以不执行某些节点，因为根据规划时不可用的参数值能确定这些节点无法产生任何行。
+   （当前，这仅会在扫描分区表的Append或MergeAppend节点的子节点中发生。）
+    发生这种情况时，将从<command>EXPLAIN</command>输出中省略这些计划节点，并显示<literal>Subplans Removed：<replaceable>N</replaceable></literal>的标识。
    </para>
   </sect2>
 
@@ -1842,6 +1846,15 @@ ____________________________________________________________________________-->
     <primary>pg_statistic_ext</primary>
    </indexterm>
 
+<!--==========================orignal english content==========================
+   <indexterm>
+    <primary>pg_statistic_ext_data</primary>
+   </indexterm>
+____________________________________________________________________________-->
+   <indexterm>
+    <primary>pg_statistic_ext_data</primary>
+   </indexterm>
+
 <!--==========================orignal english content==========================
    <para>
     It is common to see slow queries running bad execution plans because
@@ -1881,12 +1894,13 @@ ____________________________________________________________________________-->
     interest in the statistics.  Actual data collection is performed
     by <command>ANALYZE</command> (either a manual command, or background
     auto-analyze).  The collected values can be examined in the
-    <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>
+    <link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link>
+
     catalog.
    </para>
 ____________________________________________________________________________-->
    <para>
-    统计信息对象可以使用<xref linkend="sql-createstatistics"/>命令创建。这样一个对象的创建仅仅是创建了一个目录项来表示对统计信息有兴趣。实际的数据收集是由<command>ANALYZE</command>（或者是一个手工命令，或者是后台的自动分析）执行的。收集到的值可以在<link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>目录中看到。
+    统计信息对象可以使用<xref linkend="sql-createstatistics"/>命令创建。这样一个对象的创建仅仅是创建了一个目录项来表示对统计信息有兴趣。实际的数据收集是由<command>ANALYZE</command>（或者是一个手工命令，或者是后台的自动分析）执行的。收集到的值可以在<link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link>目录中看到。
    </para>
 
 <!--==========================orignal english content==========================
@@ -1999,14 +2013,14 @@ ____________________________________________________________________________-->
     <para>
      这里是一个收集函数依赖统计信息的例子：
 <programlisting>
-CREATE STATISTICS stts (dependencies) ON zip, city FROM zipcodes;
+CREATE STATISTICS stts (dependencies) ON city, zip FROM zipcodes;
 
 ANALYZE zipcodes;
 
-SELECT stxname, stxkeys, stxdependencies
-  FROM pg_statistic_ext
+SELECT stxname, stxkeys, stxddependencies
+  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
   WHERE stxname = 'stts';
- stxname | stxkeys |             stxdependencies               
+ stxname | stxkeys |             stxddependencies             
 ---------+---------+------------------------------------------
  stts    | 1 5     | {"1 => 5": 1.000000, "5 => 1": 0.423130}
 (1 row)
@@ -2154,12 +2168,12 @@ ____________________________________________________________________________-->
     <para>
      继续之前的例子，ZIP代码表中的可区分值计数可能像这样：
 <programlisting>
-CREATE STATISTICS stts2 (ndistinct) ON zip, state, city FROM zipcodes;
+CREATE STATISTICS stts2 (ndistinct) ON city, state, zip FROM zipcodes;
 
 ANALYZE zipcodes;
 
-SELECT stxkeys AS k, stxndistinct AS nd
-  FROM pg_statistic_ext
+SELECT stxkeys AS k, stxdndistinct AS nd
+  FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid)
   WHERE stxname = 'stts2';
 -[ RECORD 1 ]--------------------------------------------------------
 k  | 1 2 5
@@ -2181,6 +2195,89 @@ ____________________________________________________________________________-->
      建议只对实际用于分组的列组合以及分组数错误估计导致了糟糕计划的列组合创建<literal>ndistinct</literal>统计信息对象。否则，<command>ANALYZE</command>循环只会被浪费。
     </para>
    </sect3>
+
+   <sect3>
+<!--==========================orignal english content==========================
+    <title>Multivariate MCV Lists</title>
+____________________________________________________________________________-->
+    <title>多元MCV列表</title>
+
+<!--==========================orignal english content==========================
+    <para>
+     Another type of statistics stored for each column are most-common value
+     lists.  This allows very accurate estimates for individual columns, but
+     may result in significant misestimates for queries with conditions on
+     multiple columns.
+    </para>
+____________________________________________________________________________-->
+    <para>
+     为每列存储的另一种统计信息是频繁值列表。 这样可以对单个列进行非常准确的估计，但是对于在多个列上具有条件的查询，可能会导致严重的错误估计。
+    </para>
+
+<!--==========================orignal english content==========================
+    <para>
+     To improve such estimates, <command>ANALYZE</command> can collect MCV
+     lists on combinations of columns.  Similarly to functional dependencies
+     and n-distinct coefficients, it's impractical to do this for every
+     possible column grouping.  Even more so in this case, as the MCV list
+     (unlike functional dependencies and n-distinct coefficients) does store
+     the common column values.  So data is collected only for those groups
+     of columns appearing together in a statistics object defined with the
+     <literal>mcv</literal> option.
+    </para>
+____________________________________________________________________________-->
+    <para>
+     为了改善这种估计，<command>ANALYZE</command>可以收集列组合上的MCV列表。
+     与功能依赖和n-distinct系数类似，对每种可能的列分组进行此操作都是不切实际的。 
+     在这种情况下，甚至更是如此，因为MCV列表（与功能依赖性和n-distinct系数不同）存储了公共列值。
+     因此，仅收集在使用<literal>mcv</literal>选项定义的统计对象中同时出现的那些列组的数据。
+    </para>
+
+    <para>
+     继续前面的示例，邮政编码表的MCV列表可能类似于以下内容（与更简单的统计信息不同，它需要一个函数来检查MCV内容）:
+
+<programlisting>
+CREATE STATISTICS stts3 (mcv) ON city, state FROM zipcodes;
+
+ANALYZE zipcodes;
+
+SELECT m.* FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid),
+                pg_mcv_list_items(stxdmcv) m WHERE stxname = 'stts3';
+
+ index |         values         | nulls | frequency | base_frequency 
+-------+------------------------+-------+-----------+----------------
+     0 | {Washington, DC}       | {f,f} |  0.003467 |        2.7e-05
+     1 | {Apo, AE}              | {f,f} |  0.003067 |        1.9e-05
+     2 | {Houston, TX}          | {f,f} |  0.002167 |       0.000133
+     3 | {El Paso, TX}          | {f,f} |     0.002 |       0.000113
+     4 | {New York, NY}         | {f,f} |  0.001967 |       0.000114
+     5 | {Atlanta, GA}          | {f,f} |  0.001633 |        3.3e-05
+     6 | {Sacramento, CA}       | {f,f} |  0.001433 |        7.8e-05
+     7 | {Miami, FL}            | {f,f} |    0.0014 |          6e-05
+     8 | {Dallas, TX}           | {f,f} |  0.001367 |        8.8e-05
+     9 | {Chicago, IL}          | {f,f} |  0.001333 |        5.1e-05
+   ...
+(99 rows)
+</programlisting>
+     这表明城市和州的最常见组合是华盛顿特区，实际频率（在样本中）约为0.35%。
+     组合的基本频率（根据简单的每列频率计算）仅为0.0027％，导致两个数量级的低估。
+    </para>
+
+<!--==========================orignal english content==========================
+    <para>
+     It's advisable to create <acronym>MCV</acronym> statistics objects only
+     on combinations of columns that are actually used in conditions together,
+     and for which misestimation of the number of groups is resulting in bad
+     plans.  Otherwise, the <command>ANALYZE</command> and planning cycles
+     are just wasted.
+    </para>
+____________________________________________________________________________-->
+    <para>
+     建议仅在实际在条件中一起使用的列的组合上创建<acronym>MCV</acronym>统计对象，对于这些组合，错误估计组数会导致糟糕的执行计划。
+     否则，只会浪费<command>ANALYZE</command>和规划时间。
+    </para>
+   </sect3>
+
   </sect2>
  </sect1>
 
@@ -2825,7 +2922,7 @@ ____________________________________________________________________________-->
 
   <sect2 id="populate-pg-dump">
 <!--==========================orignal english content==========================
-   <title>Some Notes About <application>pg_dump</application></title>
+   <title>Some Notes about <application>pg_dump</application></title>
 ____________________________________________________________________________-->
    <title>关于<application>pg_dump</application>的一些注记</title>
 

postgresql/doc/src/sgml/pgstatstatements.sgml

@@ -643,30 +643,41 @@ ____________________________________________________________________________-->
   <variablelist>
    <varlistentry>
 <!--==========================orignal english content==========================
-   <term>
-     <function>pg_stat_statements_reset() returns void</function>
+    <term>
+     <function>pg_stat_statements_reset(userid Oid, dbid Oid, queryid bigint) returns void</function>
      <indexterm>
       <primary>pg_stat_statements_reset</primary>
      </indexterm>
     </term>
 ____________________________________________________________________________-->
-   <term>
-     <function>pg_stat_statements_reset() 返回 void</function>
-   <indexterm>
-    <primary>pg_stat_statements_reset</primary>
-   </indexterm>
+    <term>
+     <function>pg_stat_statements_reset(userid Oid, dbid Oid, queryid bigint) returns void</function>
+     <indexterm>
+      <primary>pg_stat_statements_reset</primary>
+     </indexterm>
     </term>
 
     <listitem>
 <!--==========================orignal english content==========================
      <para>
-      <function>pg_stat_statements_reset</function> discards all statistics
-      gathered so far by <filename>pg_stat_statements</filename>.
-      By default, this function can only be executed by superusers.
+      <function>pg_stat_statements_reset</function> discards statistics
+      gathered so far by <filename>pg_stat_statements</filename> corresponding
+      to the specified <structfield>userid</structfield>, <structfield>dbid</structfield>
+      and <structfield>queryid</structfield>.  If any of the parameters are not
+      specified, the default value <literal>0</literal>(invalid) is used for
+      each of them and the statistics that match with other parameters will be
+      reset.  If no parameter is specified or all the specified parameters are
+      <literal>0</literal>(invalid), it will discard all statistics.  By
+      default, this function can only be executed by superusers.  Access may be
+      granted to others using <command>GRANT</command>.
      </para>
 ____________________________________________________________________________-->
      <para>
-      <function>pg_stat_statements_reset</function>抛弃目前由<filename>pg_stat_statements</filename>收集的所有统计信息。默认情况下，这个函数只能被超级用户执行。
+      <function>pg_stat_statements_reset</function>丢弃到目前为止与指定的<structfield>userid</structfield>，
+      <structfield>dbid</structfield>和<structfield>queryid</structfield>相对应的<filename>pg_stat_statements</filename>收集的统计信息。 
+      如果有任何参数未被指定，那么将对这些参数使用默认值<literal>0</literal>（无效），并且将重置与其他参数匹配的统计信息。
+      如果未指定任何参数，或者所有指定的参数均为<literal>0</literal>（无效），则它将丢弃所有统计信息。
+      默认情况下，此功能只能由超级用户执行。可以使用<command>GRANT</command>授予其他人访问权限。
      </para>
     </listitem>
    </varlistentry>
@@ -948,36 +959,87 @@ bench=# \x
 bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /
                nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
           FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;
--[ RECORD 1 ]---------------------------------------------------------------------
-query       | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2;
+-[ RECORD 1 ]--------------------------------------------------------------------
+query       | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
 calls       | 3000
-total_time  | 9609.00100000002
-rows        | 2836
-hit_percent | 99.9778970000200936
--[ RECORD 2 ]---------------------------------------------------------------------
-query       | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2;
+total_time  | 25565.855387
+rows        | 3000
+hit_percent | 100.0000000000000000
+-[ RECORD 2 ]--------------------------------------------------------------------
+query       | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
 calls       | 3000
-total_time  | 8015.156
-rows        | 2990
-hit_percent | 99.9731126579631345
--[ RECORD 3 ]---------------------------------------------------------------------
+total_time  | 20756.669379
+rows        | 3000
+hit_percent | 100.0000000000000000
+-[ RECORD 3 ]--------------------------------------------------------------------
 query       | copy pgbench_accounts from stdin
 calls       | 1
-total_time  | 310.624
+total_time  | 291.865911
 rows        | 100000
-hit_percent | 0.30395136778115501520
--[ RECORD 4 ]---------------------------------------------------------------------
-query       | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2;
+hit_percent | 100.0000000000000000
+-[ RECORD 4 ]--------------------------------------------------------------------
+query       | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
 calls       | 3000
-total_time  | 271.741999999997
+total_time  | 271.232977
 rows        | 3000
-hit_percent | 93.7968855088209426
--[ RECORD 5 ]---------------------------------------------------------------------
+hit_percent | 98.5723926698852723
+-[ RECORD 5 ]--------------------------------------------------------------------
 query       | alter table pgbench_accounts add primary key (aid)
 calls       | 1
-total_time  | 81.42
+total_time  | 160.588563
 rows        | 0
-hit_percent | 34.4947735191637631
+hit_percent | 100.0000000000000000
+
+
+bench=# SELECT pg_stat_statements_reset(0,0,s.queryid) FROM pg_stat_statements AS s
+            WHERE s.query = 'UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2';
+
+bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /
+               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
+          FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;
+-[ RECORD 1 ]--------------------------------------------------------------------
+query       | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
+calls       | 3000
+total_time  | 20756.669379
+rows        | 3000
+hit_percent | 100.0000000000000000
+-[ RECORD 2 ]--------------------------------------------------------------------
+query       | copy pgbench_accounts from stdin
+calls       | 1
+total_time  | 291.865911
+rows        | 100000
+hit_percent | 100.0000000000000000
+-[ RECORD 3 ]--------------------------------------------------------------------
+query       | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
+calls       | 3000
+total_time  | 271.232977
+rows        | 3000
+hit_percent | 98.5723926698852723
+-[ RECORD 4 ]--------------------------------------------------------------------
+query       | alter table pgbench_accounts add primary key (aid)
+calls       | 1
+total_time  | 160.588563
+rows        | 0
+hit_percent | 100.0000000000000000
+-[ RECORD 5 ]--------------------------------------------------------------------
+query       | vacuum analyze pgbench_accounts
+calls       | 1
+total_time  | 136.448116
+rows        | 0
+hit_percent | 99.9201915403032721
+
+bench=# SELECT pg_stat_statements_reset(0,0,0);
+
+bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /
+               nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
+          FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;
+-[ RECORD 1 ]---------------------------------------
+query       | SELECT pg_stat_statements_reset(0,0,0)
+calls       | 1
+total_time  | 0.189497
+rows        | 1
+hit_percent | 
+
 </screen>
  </sect2>