Documentation spell checking and markup improvements

This commit is contained in:
Peter Eisentraut 2018-06-29 21:26:41 +02:00
parent 539f32bdd6
commit f7481d2c3c
9 changed files with 28 additions and 28 deletions

View File

@ -2148,7 +2148,7 @@ include_dir 'conf.d'
pool of processes established by <xref
linkend="guc-max-worker-processes"/>, limited by <xref
linkend="guc-max-parallel-workers"/>. Note that the requested
number of workers may not actually be available at runtime.
number of workers may not actually be available at run time.
If this occurs, the utility operation will run with fewer
workers than expected. The default value is 2. Setting this
value to 0 disables the use of parallel workers by utility
@ -8856,7 +8856,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
<listitem>
<para>
Writes the generated <productname>LLVM</productname> IR out to the
filesystem, inside <xref linkend="guc-data-directory"/>. This is only
file system, inside <xref linkend="guc-data-directory"/>. This is only
useful for working on the internals of the JIT implementation.
The default setting is <literal>off</literal>, and it can only be

View File

@ -9737,10 +9737,10 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
<entry>
reduce each value in the document, specified by <replaceable class="parameter">filter</replaceable> to a <type>tsvector</type>,
and then concatenate those in document order to produce a single <type>tsvector</type>.
<replaceable class="parameter">filter</replaceable> is a jsonb array, that enumerates what kind of elements need to be included
<replaceable class="parameter">filter</replaceable> is a <type>jsonb</type> array, that enumerates what kind of elements need to be included
into the resulting <type>tsvector</type>. Possible values for <replaceable class="parameter">filter</replaceable> are
<literal>"string"</literal> (to include all string values), <literal>"numeric"</literal> (to include all numeric values in the string format),
<literal>"boolean"</literal> (to include all boolean values in the string format "true"/"false"),
<literal>"boolean"</literal> (to include all Boolean values in the string format <literal>"true"</literal>/<literal>"false"</literal>),
<literal>"key"</literal> (to include all keys) or <literal>"all"</literal> (to include all above). These values
can be combined together to include, e.g. all string and numeric values.
</entry>

View File

@ -23,7 +23,7 @@
<para>
Just-in-time compilation (<acronym>JIT</acronym>) is the process of turning
some form of interpreted program evaluation into a native program, and
doing so at runtime.
doing so at run time.
For example, instead of using a facility that can evaluate arbitrary SQL
expressions to evaluate an SQL predicate like <literal>WHERE a.col =
@ -81,7 +81,7 @@
<title>Inlining</title>
<para>
<productname>PostgreSQL</productname> is very extensible and allows new
datatypes, functions, operators and other database objects to be defined;
data types, functions, operators and other database objects to be defined;
see <xref linkend="extend"/>. In fact the built-in ones are implemented
using nearly the same mechanisms. This extensibility implies some
overhead, for example due to function calls (see <xref linkend="xfunc"/>).
@ -110,18 +110,18 @@
</para>
<para>
The cost of the query will be compared with <xref
linkend="guc-jit-above-cost"/> GUC. If the cost is higher,
The cost of the query will be compared with the setting of <xref
linkend="guc-jit-above-cost"/>. If the cost is higher,
<acronym>JIT</acronym> compilation will be performed.
</para>
<para>
If the planner, based on the above criterion, decided that
<acronym>JIT</acronym> compilation is beneficial, two further decisions are
made. Firstly, if the query is more costly than the <xref
linkend="guc-jit-optimize-above-cost"/> GUC, expensive optimizations are
made. Firstly, if the query is more costly than the setting of <xref
linkend="guc-jit-optimize-above-cost"/>, expensive optimizations are
used to improve the generated code. Secondly, if the query is more costly
than the <xref linkend="guc-jit-inline-above-cost"/> GUC, short functions
than the setting of <xref linkend="guc-jit-inline-above-cost"/>, short functions
and operators used in the query will be inlined. Both of these operations
increase the <acronym>JIT</acronym> overhead, but can reduce query
execution time considerably.
@ -131,7 +131,7 @@
This cost based decision will be made at plan time, not execution
time. This means that when prepared statements are in use, and the generic
plan is used (see <xref linkend="sql-prepare-notes"/>), the values of the
GUCs set at prepare time take effect, not the settings at execution time.
configuration parameters set at prepare time take effect, not the settings at execution time.
</para>
<note>
@ -208,7 +208,7 @@ SET
</para>
<para>
For development and debugging purposes a few additional GUCs exist. <xref
For development and debugging purposes a few additional configuration parameters exist. <xref
linkend="guc-jit-dump-bitcode"/> allows the generated bitcode to be
inspected. <xref linkend="guc-jit-debugging-support"/> allows GDB to see
generated functions. <xref linkend="guc-jit-profiling-support"/> emits
@ -245,7 +245,7 @@ SET
to <filename>$pkglibdir/bitcode/$extension.index.bc</filename>, where
<literal>$pkglibdir</literal> is the directory returned by
<literal>pg_config --pkglibdir</literal> and <literal>$extension</literal>
the basename of the extension's shared library.
the base name of the extension's shared library.
<note>
<para>
@ -264,8 +264,8 @@ SET
<productname>PostgreSQL</productname> provides a <acronym>JIT</acronym>
implementation based on <productname>LLVM</productname>. The interface to
the <acronym>JIT</acronym> provider is pluggable and the provider can be
changed without recompiling. The provider is chosen via the <xref
linkend="guc-jit-provider"/> <acronym>GUC</acronym>.
changed without recompiling. The provider is chosen via the setting <xref
linkend="guc-jit-provider"/>.
</para>
<sect3>

View File

@ -923,12 +923,12 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
<para>
In the connection URI format, you can list multiple <literal>host:port</literal> pairs
separated by commas, in the <literal>host</literal> component of the URI. In either
format, a single hostname can also translate to multiple network addresses. A
format, a single host name can also translate to multiple network addresses. A
common example of this is a host that has both an IPv4 and an IPv6 address.
</para>
<para>
When multiple hosts are specified, or when a single hostname is
When multiple hosts are specified, or when a single host name is
translated to multiple addresses, all the hosts and addresses will be
tried in order, until one succeeds. If none of the hosts can be reached,
the connection fails. If a connection is established successfully, but

View File

@ -161,7 +161,7 @@ EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);
multiply their selectivities together to arrive at a much-too-small
row count estimate.
With such statistics, the planner recognizes that the <literal>WHERE</literal>
conditions are redundant and does not underestimate the rowcount.
conditions are redundant and does not underestimate the row count.
</para>
</refsect1>

View File

@ -511,7 +511,7 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
<listitem>
<para>
Show progress report every <replaceable>sec</replaceable> seconds. The report
includes the time since the beginning of the run, the tps since the
includes the time since the beginning of the run, the TPS since the
last report, and the transaction latency average and standard
deviation since the last report. Under throttling (<option>-R</option>),
the latency is computed with respect to the transaction scheduled
@ -727,9 +727,9 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
</para>
<para>
Remember to take the sampling rate into account when processing the
log file. For example, when computing tps values, you need to multiply
log file. For example, when computing TPS values, you need to multiply
the numbers accordingly (e.g. with 0.01 sample rate, you'll only get
1/100 of the actual tps).
1/100 of the actual TPS).
</para>
</listitem>
</varlistentry>
@ -967,7 +967,7 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
Sets variable <replaceable>varname</replaceable> to a value calculated
from <replaceable>expression</replaceable>.
The expression may contain the <literal>NULL</literal> constant,
boolean constants <literal>TRUE</literal> and <literal>FALSE</literal>,
Boolean constants <literal>TRUE</literal> and <literal>FALSE</literal>,
integer constants such as <literal>5432</literal>,
double constants such as <literal>3.14159</literal>,
references to variables <literal>:</literal><replaceable>variablename</replaceable>,
@ -1485,7 +1485,7 @@ f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
</listitem>
<listitem>
<para>
<literal>random_zipfian</literal> generates an approximated bounded zipfian
<literal>random_zipfian</literal> generates an approximated bounded Zipfian
distribution. For <replaceable>parameter</replaceable> in (0, 1), an
approximated algorithm is taken from
"Quickly Generating Billion-Record Synthetic Databases",

View File

@ -558,7 +558,7 @@ EOF
<listitem>
<para>
Set the field separator for unaligned output to a zero byte. This is
equvalent to <command>\pset fieldsep_zero</command>.
equivalent to <command>\pset fieldsep_zero</command>.
</para>
</listitem>
</varlistentry>

View File

@ -1233,7 +1233,7 @@ same commits as above
</para>
<para>
Specifically, "ldapsearchfilter" allows pattern matching using
Specifically, <literal>ldapsearchfilter</literal> allows pattern matching using
combinations of <acronym>LDAP</acronym> attributes.
</para>
</listitem>
@ -2673,7 +2673,7 @@ same commits as above
-->
<para>
Speed up lookups of builtin function names matching oids (Andres
Speed up lookups of built-in function names matching OIDs (Andres
Freund)
</para>

View File

@ -565,7 +565,7 @@ DROP ROLE doomed_role;
<literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
trusted, but non-superuser, roles which are able to access files and run programs on the
database server as the user the database runs as. As these roles are able to access any file on
the server filesystem, they bypass all database-level permission checks when accessing files
the server file system, they bypass all database-level permission checks when accessing files
directly and they could be used to gain superuser-level access, therefore care should be taken
when granting these roles to users.
</para>