Skip to content

Commit d6d4920

Browse files
committed
9.5上修正的部分翻译问题反馈到9.6
1 parent 74f3ad2 commit d6d4920

File tree

3 files changed

+3
-4
lines changed

3 files changed

+3
-4
lines changed

postgresql/doc/src/sgml/catalogs.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -13685,7 +13685,7 @@ ____________________________________________________________________________-->
1368513685
____________________________________________________________________________-->
1368613686
<row>
1368713687
<entry><literal>X</literal></entry>
13688-
<entry><type>位置</>类型</entry>
13688+
<entry><type>未知</>类型</entry>
1368913689
</row>
1369013690
</tbody>
1369113691
</tgroup>

postgresql/doc/src/sgml/indices.sgml

+1-2
Original file line numberDiff line numberDiff line change
@@ -2209,8 +2209,7 @@ ____________________________________________________________________________-->
22092209
in a running server, as described in <xref linkend="monitoring-stats">.
22102210
</para>
22112211
____________________________________________________________________________-->
2212-
<para>
2213-
Although indexes in 尽管<productname>PostgreSQL</>中的索引并不需要维护或调优,但是检查真实的查询负载实际使用了哪些索引仍然非常重要。检查一个独立查询的索引使用情况可以使用<xref linkend="sql-explain">命令,它应用于这种目的的内容在<xref linkend="using-explain">中有介绍。也可以在一个运行中的服务器上收集有关索引使用的总体统计情况,如<xref linkend="monitoring-stats">所述。
2212+
<para> 尽管<productname>PostgreSQL</>中的索引并不需要维护或调优,但是检查真实的查询负载实际使用了哪些索引仍然非常重要。检查一个独立查询的索引使用情况可以使用<xref linkend="sql-explain">命令,它应用于这种目的的内容在<xref linkend="using-explain">中有介绍。也可以在一个运行中的服务器上收集有关索引使用的总体统计情况,如<xref linkend="monitoring-stats">所述。
22142213
</para>
22152214

22162215
<!--==========================orignal english content==========================

postgresql/doc/src/sgml/wal.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -915,7 +915,7 @@ ____________________________________________________________________________-->
915915
</para>
916916
____________________________________________________________________________-->
917917
<para>
918-
有两个常用的内部<acronym>WAL</acronym>函数:<function>XLogInsertRecord</function>和<function>XLogFlush</function>。 <function>XLogInsertRecord</function>用于向共享内存中的<acronym>WAL</acronym>缓冲区里放置一个新记录。如果没有空间存放新记录, 那么<function>XLogInsertRecord</function>就不得不写出(向内核缓存里写)一些填满了的<acronym>WAL</acronym>缓冲区。 这并非我们所期望的,因为<function>XLogInsertRecord</function>用于每次数据库低层修改(比如,记录插入)时都要在受影响的数据页上持有一个排它锁,因为该操作需要越快越好。但糟糕的是, 写<acronym>WAL</acronym>缓冲可能还会强制创建新的日志段,这花的时间甚至更多。通常,<acronym>WAL</acronym>缓冲区应该由一个<function>XLogFlush</function>请求来写和刷出, 在大部分时候它都是发生在事务提交的时候以确保事务记录被刷写到永久存储。在那些日志输出量比较大的系统上,<function>XLogFlush</function>请求可能不够频繁,这样就不能避免<function>XLogInsert</function>进行写操作。在这样的系统上,我们应该通过修改配置参数 <xref linkend="guc-full-page-writes">的值来增加<acronym>WAL</acronym>缓冲区的数量。如果设置了 <xref linkend="guc-full-page-writes">并且系统相当繁忙, 把<varname>wal_buffers</>设置得更高一些将有助于在紧随每个检查点之后的时间段里得到平滑的响应时间。
918+
有两个常用的内部<acronym>WAL</acronym>函数:<function>XLogInsertRecord</function>和<function>XLogFlush</function>。 <function>XLogInsertRecord</function>用于向共享内存中的<acronym>WAL</acronym>缓冲区里放置一个新记录。如果没有空间存放新记录, 那么<function>XLogInsertRecord</function>就不得不写出(向内核缓存里写)一些填满了的<acronym>WAL</acronym>缓冲区。 这并非我们所期望的,因为<function>XLogInsertRecord</function>用于每次数据库低层修改(比如,记录插入)时都要在受影响的数据页上持有一个排它锁,因为该操作需要越快越好。但糟糕的是, 写<acronym>WAL</acronym>缓冲可能还会强制创建新的日志段,这花的时间甚至更多。通常,<acronym>WAL</acronym>缓冲区应该由一个<function>XLogFlush</function>请求来写和刷出, 在大部分时候它都是发生在事务提交的时候以确保事务记录被刷写到永久存储。在那些日志输出量比较大的系统上,<function>XLogFlush</function>请求可能不够频繁,这样就不能避免<function>XLogInsert</function>进行写操作。在这样的系统上,我们应该通过修改配置参数 <xref linkend="guc-wal-buffers">的值来增加<acronym>WAL</acronym>缓冲区的数量。如果设置了 <xref linkend="guc-full-page-writes">并且系统相当繁忙, 把<varname>wal_buffers</>设置得更高一些将有助于在紧随每个检查点之后的时间段里得到平滑的响应时间。
919919
</para>
920920

921921
<!--==========================orignal english content==========================

0 commit comments

Comments
 (0)