Merge pull request #391 from sirlipeng/master

翻译14.1 by sirlipeng 2022/09/01

Author: ChenHuajun

postgresql/doc/src/sgml/hash.sgml

@@ -1,16 +1,29 @@
 <!-- doc/src/sgml/hash.sgml -->
 
 <chapter id="hash-index">
+<!--==========================orignal english content==========================
 <title>Hash Indexes</title>
+____________________________________________________________________________-->
+<title>哈希索引</title>
 
+<!--==========================orignal english content==========================
    <indexterm>
     <primary>index</primary>
     <secondary>Hash</secondary>
    </indexterm>
+____________________________________________________________________________-->
+   <indexterm>
+    <primary>索引</primary>
+    <secondary>哈希</secondary>
+   </indexterm>
 
 <sect1 id="hash-intro">
+<!--==========================orignal english content==========================
  <title>Overview</title>
+____________________________________________________________________________-->
+ <title>概述</title>
 
+<!--==========================orignal english content==========================
  <para>
   <productname>PostgreSQL</productname>
   includes an implementation of persistent on-disk hash indexes,
@@ -20,26 +33,47 @@
   indexed, thus there are no restrictions on the size of the data column
   being indexed.
  </para>
+____________________________________________________________________________-->
+ <para>
+  <productname>PostgreSQL</productname>
+  包含永久性磁盘上的哈希索引的实现，这些索引可完全崩溃恢复。任何数据类型都可以通过哈希索引进行索引，包括没有明确定义线性排序的数据类型。哈希索引只存储被索引数据的哈希值，因此对被索引数据列的大小没有限制。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Hash indexes support only single-column indexes and do not allow
   uniqueness checking.
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引仅支持单列索引并且不允许唯一性检查。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Hash indexes support only the <literal>=</literal> operator,
   so WHERE clauses that specify range operations will not be able to take
   advantage of hash indexes.
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引仅支持<literal>=</literal>运算符，因此使用了范围操作的WHERE子句将无法利用哈希索引。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Each hash index tuple stores just the 4-byte hash value, not the actual
   column value. As a result, hash indexes may be much smaller than B-trees
   when indexing longer data items such as UUIDs, URLs, etc. The absence of
   the column value also makes all hash index scans lossy. Hash indexes may
   take part in bitmap index scans and backward scans.
  </para>
+____________________________________________________________________________-->
+ <para>
+  每个哈希索引元组只存储4字节的哈希值，而不是实际的列值。因此，当索引较长的数据项（如UUID、URL等）时，哈希索引可能比B树小得多。缺少列值也会使所有哈希索引扫描有损。哈希索引可以参与位图索引扫描和反向扫描。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Hash indexes are best optimized for SELECT and UPDATE-heavy workloads
   that use equality scans on larger tables. In a B-tree index, searches must
@@ -51,7 +85,12 @@
   reduction in "logical I/O" becomes even more pronounced on indexes/data
   larger than shared_buffers/RAM. 
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引对于在较大表上使用相等扫描的SELECT和UPDATE的繁重工作进行了最佳优化。在B树索引中，搜索必须在树中向下搜索，直到找到叶子页。在具有数百万行的表中，这种向下搜索会增加数据访问时间。哈希索引中叶子页的等价物称为桶页。相反，哈希索引允许直接访问桶页，从而可能减少较大表中的索引访问时间。在大于shared_buffers/RAM的索引/数据上，这种“逻辑I/O”的减少变得更加明显。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Hash indexes have been designed to cope with uneven distributions of
   hash values. Direct access to the bucket pages works well if the hash
@@ -63,7 +102,12 @@
   might actually be worse than a B-tree in terms of number of block
   accesses required, for some data.
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引被设计用于处理哈希值的不均匀分布。如果哈希值均匀分布，则直接访问桶页效果良好。当插入使得桶页变满时，额外的溢出页链接到该特定的桶页，本地扩展存储来容纳与该哈希值匹配的索引元组。在查询期间扫描哈希桶时，我们需要扫描所有溢出页。因此，就某些数据所需的块访问数而言，不平衡散列索引实际上可能比B树更差。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   As a result of the overflow cases, we can say that hash indexes are
   most suitable for unique, nearly unique data or data with a low number
@@ -72,7 +116,13 @@
   values from the index using a partial index condition, but this may
   not be suitable in many cases.
  </para>
+____________________________________________________________________________-->
+ <para>
+  通过溢出情况得到的结论是，我们可以说哈希索引最适合于唯一、几乎唯一的数据或每个哈希桶的行数较少的数据。
+  避免问题的一种可能方法是使用部分索引条件从索引中排除高度非唯一的值，但这在许多情况下可能不适用。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Like B-Trees, hash indexes perform simple index tuple deletion. This
   is a deferred maintenance operation that deletes index tuples that are
@@ -82,7 +132,12 @@
   index tuples. Removal cannot occur if the page is pinned at that time.
   Deletion of dead index pointers also occurs during VACUUM.
  </para>
+____________________________________________________________________________-->
+ <para>
+  与B树一样，哈希索引执行简单的索引元组删除。这是一个延迟维护操作，用于删除已知可以安全删除的索引元组（其项标识符的LP_DEAD位已设置的那些）。如果insert发现页面上没有可用空间，我们会尝试通过删除死索引元组来避免创建新的溢出页面。如果此时页面已被锁定，则无法删除。VACUUM期间也会删除死索引指针。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   If it can, VACUUM will also try to squeeze the index tuples onto as
   few overflow pages as possible, minimizing the overflow chain. If an
@@ -92,7 +147,12 @@
   rebuilding it with REINDEX.  
   There is no provision for reducing the number of buckets, either.
  </para>
+____________________________________________________________________________-->
+ <para>
+  如果可以，VACUUM还将尝试将索引元组压缩到尽可能少的溢出页上，以最小化溢出链。如果溢出页变为空，溢出页可以被回收以在其他桶中重用，尽管我们从未将它们返回到操作系统。目前，除了使用REINDEX重建哈希索引外，没有任何收缩哈希索引的方法。也没有减少桶数量的方法。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Hash indexes may expand the number of bucket pages as the number of
   rows indexed grows. The hash key-to-bucket-number mapping is chosen so that
@@ -101,26 +161,44 @@
   its tuples being transferred to the new bucket according to the updated
   key-to-bucket-number mapping.
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引可能会随着索引行数的增加而扩展桶页数。选择哈希键到桶号的映射，以便可以增量扩展索引。当一个新的桶要添加到索引中时，只需要“拆分”一个现有的桶，其中的一些元组将根据更新后的key到桶号的映射转移到新桶。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   The expansion occurs in the foreground, which could increase execution
   time for user inserts. Thus, hash indexes may not be suitable for tables
   with rapidly increasing number of rows.
  </para>
+____________________________________________________________________________-->
+ <para>
+  扩展发生在前端，这可能会增加用户插入的执行时间。因此，哈希索引可能不适用于行数快速增加的表。
+ </para>
 
 </sect1>
 
 <sect1 id="hash-implementation">
+<!--==========================orignal english content==========================
  <title>Implementation</title>
+____________________________________________________________________________-->
+ <title>实现</title>
 
+<!--==========================orignal english content==========================
  <para>
   There are four kinds of pages in a hash index: the meta page (page zero),
   which contains statically allocated control information; primary bucket
   pages; overflow pages; and bitmap pages, which keep track of overflow
   pages that have been freed and are available for re-use. For addressing
   purposes, bitmap pages are regarded as a subset of the overflow pages.
  </para>
+____________________________________________________________________________-->
+ <para>
+  哈希索引中有四种页面：元页面（零页），其中包含静态分配的控制信息；主桶页；溢出页；和位图页，它们跟踪已释放并可供重用的溢出页。出于寻址目的，位图页被视为溢出页的子集。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Both scanning the index and inserting tuples require locating the bucket
   where a given tuple ought to be located. To do this, we need the bucket
@@ -131,15 +209,25 @@
   mapping as long as the target bucket hasn't been split since the last
   cache refresh.
  </para>
+____________________________________________________________________________-->
+ <para>
+  扫描索引和插入元组都需要定位给定元组应该位于的桶。为此，我们需要元页面中的桶计数、highmask和lowmask；然而，出于性能原因，必须为每个此类操作加锁和锁定元页是不可取的。相反，我们在每个后端的relcache条目中保留了元页面的缓存副本。只要目标桶自上次缓存刷新后未被拆分，这将生成正确的桶映射。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Primary bucket pages and overflow pages are allocated independently since
   any given index might need more or fewer overflow pages relative to its
   number of buckets. The hash code uses an interesting set of addressing
   rules to support a variable number of overflow pages while not having to
   move primary bucket pages around after they are created.
  </para>
+____________________________________________________________________________-->
+ <para>
+  主桶页和溢出页是独立分配的，因为任何给定的索引相对于其桶的数量可能需要更多或更少的溢出页。哈希代码使用一组有趣的寻址规则来支持可变数量的溢出页，而不必在创建主桶页后四处移动。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   Each row in the table indexed is represented by a single index tuple in
   the hash index. Hash index tuples are stored in bucket pages, and if
@@ -148,14 +236,23 @@
   used within an index page. Note however that there is *no* assumption about
   the relative ordering of hash codes across different index pages of a bucket.
  </para>
+____________________________________________________________________________-->
+ <para>
+  索引表中的每一行由哈希索引中的单个索引元组表示。哈希索引元组存储在桶页中，如果存在，则存储在溢出页中。我们通过将任意一个索引页中的索引项按哈希代码排序来加快搜索速度，从而允许在索引页中使用二进制搜索。但是，请注意，对于一个桶的不同索引页上的哈希代码的相对排序，没有上述排序。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   The bucket splitting algorithms to expand the hash index are too complex to
   be worthy of mention here, though are described in more detail in
   <filename>src/backend/access/hash/README</filename>.
   The split algorithm is crash safe and can be restarted if not completed
   successfully.
  </para>
+____________________________________________________________________________-->
+ <para>
+  用于扩展哈希索引的桶分割算法过于复杂，不值得在此提及，下面有更详细的描述<filename>src/backend/access/hash/README</filename>。拆分算法是崩溃安全的，如果未成功完成，可以重新启动。
+ </para>
 
 </sect1>
 

postgresql/doc/src/sgml/install-binaries.sgml

@@ -1,24 +1,43 @@
 <!-- doc/src/sgml/install-binaries.sgml -->
 <chapter id="install-binaries">
+<!--==========================orignal english content==========================
  <title>Installation from Binaries</title>
+____________________________________________________________________________-->
+ <title>从二进制安装</title>
 
+<!--==========================orignal english content==========================
+ <indexterm>
+  <primary>installation</primary>
+  <secondary>binaries</secondary>
+ </indexterm>
+____________________________________________________________________________-->
  <indexterm>
   <primary>installation</primary>
   <secondary>binaries</secondary>
  </indexterm>
 
+<!--==========================orignal english content==========================
  <para>
   <productname>PostgreSQL</productname> is available in the form of binary
   packages for most common operating systems today. When available, this is
   the recommended way to install PostgreSQL for users of the system. Building
   from source (see <xref linkend="installation" />) is only recommended for
   people developing <productname>PostgreSQL</productname> or extensions.
  </para>
+____________________________________________________________________________-->
+ <para>
+  <productname>PostgreSQL</productname>以二进制软件包的形式提供给当今大多数常见的操作系统。如果可用，这是系统用户安装PostgreSQL的推荐方法。仅建议<productname>PostgreSQL</productname>的开发或扩展人员从源代码构建（请参见<xref linkend="installation" />）。
+ </para>
 
+<!--==========================orignal english content==========================
  <para>
   For an updated list of platforms providing binary packages, please visit
   the download section on the <productname>PostgreSQL</productname> website at
   <ulink url="https://www.postgresql.org/download/"></ulink> and follow the
   instructions for the specific platform.
  </para>
+____________________________________________________________________________-->
+ <para>
+  有关提供二进制软件包的平台的更新列表，请访问<productname>PostgreSQL</productname>网站上的<ulink url="https://www.postgresql.org/download/"></ulink>并遵循特定平台的说明。
+ </para>
 </chapter>

postgresql/doc/src/sgml/oldsnapshot.sgml

@@ -1,30 +1,55 @@
 <!-- doc/src/sgml/oldsnapshot.sgml -->
 
 <sect1 id="oldsnapshot" xreflabel="old_snapshot">
+<!--==========================orignal english content==========================
+ <title>old_snapshot</title>
+____________________________________________________________________________-->
  <title>old_snapshot</title>
 
+<!--==========================orignal english content==========================
+ <indexterm zone="oldsnapshot">
+  <primary>old_snapshot</primary>
+ </indexterm>
+____________________________________________________________________________-->
  <indexterm zone="oldsnapshot">
   <primary>old_snapshot</primary>
  </indexterm>
 
+<!--==========================orignal english content==========================
  <para>
   The <filename>old_snapshot</filename> module allows inspection
   of the server state that is used to implement
   <xref linkend="guc-old-snapshot-threshold" />.
  </para>
+____________________________________________________________________________-->
+ <para>
+  The <filename>old_snapshot</filename>模块用来检查用来实现
+  <xref linkend="guc-old-snapshot-threshold" />的服务器的状态。
+ </para>
 
  <sect2>
+<!--==========================orignal english content==========================
   <title>Functions</title>
+____________________________________________________________________________-->
+  <title>函数</title>
 
   <variablelist>
    <varlistentry>
+<!--==========================orignal english content==========================
     <term><function>pg_old_snapshot_time_mapping(array_offset OUT int4, end_timestamp OUT timestamptz, newest_xmin OUT xid) returns setof record</function></term>
+____________________________________________________________________________-->
+    <term><function>pg_old_snapshot_time_mapping(array_offset OUT int4, end_timestamp OUT timestamptz, newest_xmin OUT xid)returns setof record</function></term>
     <listitem>
+<!--==========================orignal english content==========================
      <para>
       Returns all of the entries in the server's timestamp to XID mapping.
       Each entry represents the newest xmin of any snapshot taken in the
       corresponding minute.
      </para>
+____________________________________________________________________________-->
+     <para>
+      返回服务器所有时间戳到XID的映射条目。每个条目表示在相应分钟内拍摄的任何快照的最新xmin。
+     </para>
     </listitem>
    </varlistentry>
   </variablelist>