Skip to content

Commit 6568fde

Browse files
committed
将多处“微妙”修正为“微秒”
1 parent 3883185 commit 6568fde

File tree

6 files changed

+11
-11
lines changed

6 files changed

+11
-11
lines changed

postgresql/doc/src/sgml/config.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4520,7 +4520,7 @@ ____________________________________________________________________________-->
45204520
</para>
45214521
____________________________________________________________________________-->
45224522
<para>
4523-
在一次 WAL 刷写被发起之前,<varname>commit_delay</varname>增加一个时间延迟,以微妙计。如果系统负载足够高,使得在一个给定间隔内有额外的事务准备好提交,那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量。但是,它也把每次 WAL 刷写的潜伏期增加到了最多<varname>commit_delay</varname>微秒。因为如果没有其他事务准备好提交,就会浪费一次延迟,只有在当一次刷写将要被发起时有至少<varname>commit_siblings</varname>个其他活动事务时,才会执行一次延迟。另外,如果<varname>fsync</varname>被禁用,则将不会执行任何延迟。默认的<varname>commit_delay</>是零(无延迟)。只有超级用户才能修改这个设置。
4523+
在一次 WAL 刷写被发起之前,<varname>commit_delay</varname>增加一个时间延迟,以微秒计。如果系统负载足够高,使得在一个给定间隔内有额外的事务准备好提交,那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量。但是,它也把每次 WAL 刷写的潜伏期增加到了最多<varname>commit_delay</varname>微秒。因为如果没有其他事务准备好提交,就会浪费一次延迟,只有在当一次刷写将要被发起时有至少<varname>commit_siblings</varname>个其他活动事务时,才会执行一次延迟。另外,如果<varname>fsync</varname>被禁用,则将不会执行任何延迟。默认的<varname>commit_delay</>是零(无延迟)。只有超级用户才能修改这个设置。
45244524
</para>
45254525
<!--==========================orignal english content==========================
45264526
<para>

postgresql/doc/src/sgml/protocol.sgml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -3662,7 +3662,7 @@ ____________________________________________________________________________-->
36623662
</term>
36633663
<listitem>
36643664
<para>
3665-
在传送时服务器的系统时钟,以从2000-01-01午夜开始的微妙计
3665+
在传送时服务器的系统时钟,以从2000-01-01午夜开始的微秒计
36663666
</para>
36673667
</listitem>
36683668
</varlistentry>
@@ -3716,7 +3716,7 @@ ____________________________________________________________________________-->
37163716
</term>
37173717
<listitem>
37183718
<para>
3719-
在传送时服务器的系统时钟,以从2000-01-01午夜开始的微妙计
3719+
在传送时服务器的系统时钟,以从2000-01-01午夜开始的微秒计
37203720
</para>
37213721
</listitem>
37223722
</varlistentry>
@@ -3796,7 +3796,7 @@ ____________________________________________________________________________-->
37963796
</term>
37973797
<listitem>
37983798
<para>
3799-
在传送时客户端的系统时钟,以从2000-01-01午夜开始的微妙计
3799+
在传送时客户端的系统时钟,以从2000-01-01午夜开始的微秒计
38003800
</para>
38013801
</listitem>
38023802
</varlistentry>
@@ -3842,7 +3842,7 @@ ____________________________________________________________________________-->
38423842
</term>
38433843
<listitem>
38443844
<para>
3845-
在传送时客户端的系统时钟,以从2000-01-01午夜开始的微妙计
3845+
在传送时客户端的系统时钟,以从2000-01-01午夜开始的微秒计
38463846
</para>
38473847
</listitem>
38483848
</varlistentry>

postgresql/doc/src/sgml/ref/pgbench.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1588,7 +1588,7 @@ ____________________________________________________________________________-->
15881588
</para>
15891589
____________________________________________________________________________-->
15901590
<para>
1591-
导致脚本执行休眠指定的时间,时间的单位可以是微妙(<literal>us</>)、毫秒(<literal>ms</>)或者秒(<literal>s</>)。如果单位被忽略,则秒是默认值。<replaceable>number</>要么是一个整数常量,要么是一个引用了具有整数值的变量的<literal>:</><replaceable>variablename</>。
1591+
导致脚本执行休眠指定的时间,时间的单位可以是微秒(<literal>us</>)、毫秒(<literal>ms</>)或者秒(<literal>s</>)。如果单位被忽略,则秒是默认值。<replaceable>number</>要么是一个整数常量,要么是一个引用了具有整数值的变量的<literal>:</><replaceable>variablename</>。
15921592
</para>
15931593

15941594
<!--==========================orignal english content==========================

postgresql/doc/src/sgml/ref/pgtesttiming.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -189,7 +189,7 @@ Histogram of timing durations:
189189
</para>
190190
____________________________________________________________________________-->
191191
<para>
192-
好的结果将显示大部分(>90%)的单个计时调用用时都小于 1 微妙。每次循环的平均开销将会更低,低于 100 纳秒。下面的例子来自于一台使用了一份 TSC 时钟源码的 Intel i7-860 系统,它展示了非常好的性能:
192+
好的结果将显示大部分(>90%)的单个计时调用用时都小于 1 微秒。每次循环的平均开销将会更低,低于 100 纳秒。下面的例子来自于一台使用了一份 TSC 时钟源码的 Intel i7-860 系统,它展示了非常好的性能:
193193

194194
<screen>
195195
Testing timing overhead for 3 seconds.
@@ -213,7 +213,7 @@ Histogram of timing durations:
213213
</para>
214214
____________________________________________________________________________-->
215215
<para>
216-
注意每次循环时间和柱状图用的单位是不同的。循环的解析度可以在几个纳秒(ns),而单个计时调用只能解析到一个微妙(us)。
216+
注意每次循环时间和柱状图用的单位是不同的。循环的解析度可以在几个纳秒(ns),而单个计时调用只能解析到一个微秒(us)。
217217
</para>
218218

219219
</refsect2>

postgresql/doc/src/sgml/release-8.1.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4175,7 +4175,7 @@ ____________________________________________________________________________-->
41754175
</para>
41764176
____________________________________________________________________________-->
41774177
<para>
4178-
允许<type>interval</>数据类型接受只有毫秒或微妙组成的输入 (Neil)
4178+
允许<type>interval</>数据类型接受只有毫秒或微秒组成的输入 (Neil)
41794179
</para>
41804180
</listitem>
41814181

postgresql/doc/src/sgml/release-8.2.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6308,7 +6308,7 @@ ____________________________________________________________________________-->
63086308
</para>
63096309
____________________________________________________________________________-->
63106310
<para>
6311-
正确的强制<varname>statement_timeout</>值比<literal>INT_MAX</>微妙(大约35分钟)更长 (Tom)
6311+
正确的强制<varname>statement_timeout</>值比<literal>INT_MAX</>微秒(大约35分钟)更长 (Tom)
63126312
</para>
63136313

63146314
<!--==========================orignal english content==========================
@@ -7078,7 +7078,7 @@ ____________________________________________________________________________-->
70787078
</para>
70797079
____________________________________________________________________________-->
70807080
<para>
7081-
允许<type>interval</>数据类型接受只由毫秒和微妙组成的输入 (Neil)
7081+
允许<type>interval</>数据类型接受只由毫秒和微秒组成的输入 (Neil)
70827082
</para>
70837083
</listitem>
70847084

0 commit comments

Comments
 (0)