Documentation spell checking and markup improvements
This commit is contained in:
parent
539f32bdd6
commit
f7481d2c3c
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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",
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
Loading…
x
Reference in New Issue
Block a user