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
|
pool of processes established by <xref
|
||||||
linkend="guc-max-worker-processes"/>, limited by <xref
|
linkend="guc-max-worker-processes"/>, limited by <xref
|
||||||
linkend="guc-max-parallel-workers"/>. Note that the requested
|
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
|
If this occurs, the utility operation will run with fewer
|
||||||
workers than expected. The default value is 2. Setting this
|
workers than expected. The default value is 2. Setting this
|
||||||
value to 0 disables the use of parallel workers by utility
|
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>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Writes the generated <productname>LLVM</productname> IR out to the
|
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.
|
useful for working on the internals of the JIT implementation.
|
||||||
|
|
||||||
The default setting is <literal>off</literal>, and it can only be
|
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>
|
<entry>
|
||||||
reduce each value in the document, specified by <replaceable class="parameter">filter</replaceable> to a <type>tsvector</type>,
|
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>.
|
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
|
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>"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
|
<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.
|
can be combined together to include, e.g. all string and numeric values.
|
||||||
</entry>
|
</entry>
|
||||||
|
|
|
@ -23,7 +23,7 @@
|
||||||
<para>
|
<para>
|
||||||
Just-in-time compilation (<acronym>JIT</acronym>) is the process of turning
|
Just-in-time compilation (<acronym>JIT</acronym>) is the process of turning
|
||||||
some form of interpreted program evaluation into a native program, and
|
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
|
For example, instead of using a facility that can evaluate arbitrary SQL
|
||||||
expressions to evaluate an SQL predicate like <literal>WHERE a.col =
|
expressions to evaluate an SQL predicate like <literal>WHERE a.col =
|
||||||
|
@ -81,7 +81,7 @@
|
||||||
<title>Inlining</title>
|
<title>Inlining</title>
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname> is very extensible and allows new
|
<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
|
see <xref linkend="extend"/>. In fact the built-in ones are implemented
|
||||||
using nearly the same mechanisms. This extensibility implies some
|
using nearly the same mechanisms. This extensibility implies some
|
||||||
overhead, for example due to function calls (see <xref linkend="xfunc"/>).
|
overhead, for example due to function calls (see <xref linkend="xfunc"/>).
|
||||||
|
@ -110,18 +110,18 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The cost of the query will be compared with <xref
|
The cost of the query will be compared with the setting of <xref
|
||||||
linkend="guc-jit-above-cost"/> GUC. If the cost is higher,
|
linkend="guc-jit-above-cost"/>. If the cost is higher,
|
||||||
<acronym>JIT</acronym> compilation will be performed.
|
<acronym>JIT</acronym> compilation will be performed.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If the planner, based on the above criterion, decided that
|
If the planner, based on the above criterion, decided that
|
||||||
<acronym>JIT</acronym> compilation is beneficial, two further decisions are
|
<acronym>JIT</acronym> compilation is beneficial, two further decisions are
|
||||||
made. Firstly, if the query is more costly than the <xref
|
made. Firstly, if the query is more costly than the setting of <xref
|
||||||
linkend="guc-jit-optimize-above-cost"/> GUC, expensive optimizations are
|
linkend="guc-jit-optimize-above-cost"/>, expensive optimizations are
|
||||||
used to improve the generated code. Secondly, if the query is more costly
|
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
|
and operators used in the query will be inlined. Both of these operations
|
||||||
increase the <acronym>JIT</acronym> overhead, but can reduce query
|
increase the <acronym>JIT</acronym> overhead, but can reduce query
|
||||||
execution time considerably.
|
execution time considerably.
|
||||||
|
@ -131,7 +131,7 @@
|
||||||
This cost based decision will be made at plan time, not execution
|
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
|
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
|
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>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
|
@ -208,7 +208,7 @@ SET
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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
|
linkend="guc-jit-dump-bitcode"/> allows the generated bitcode to be
|
||||||
inspected. <xref linkend="guc-jit-debugging-support"/> allows GDB to see
|
inspected. <xref linkend="guc-jit-debugging-support"/> allows GDB to see
|
||||||
generated functions. <xref linkend="guc-jit-profiling-support"/> emits
|
generated functions. <xref linkend="guc-jit-profiling-support"/> emits
|
||||||
|
@ -245,7 +245,7 @@ SET
|
||||||
to <filename>$pkglibdir/bitcode/$extension.index.bc</filename>, where
|
to <filename>$pkglibdir/bitcode/$extension.index.bc</filename>, where
|
||||||
<literal>$pkglibdir</literal> is the directory returned by
|
<literal>$pkglibdir</literal> is the directory returned by
|
||||||
<literal>pg_config --pkglibdir</literal> and <literal>$extension</literal>
|
<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>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
|
@ -264,8 +264,8 @@ SET
|
||||||
<productname>PostgreSQL</productname> provides a <acronym>JIT</acronym>
|
<productname>PostgreSQL</productname> provides a <acronym>JIT</acronym>
|
||||||
implementation based on <productname>LLVM</productname>. The interface to
|
implementation based on <productname>LLVM</productname>. The interface to
|
||||||
the <acronym>JIT</acronym> provider is pluggable and the provider can be
|
the <acronym>JIT</acronym> provider is pluggable and the provider can be
|
||||||
changed without recompiling. The provider is chosen via the <xref
|
changed without recompiling. The provider is chosen via the setting <xref
|
||||||
linkend="guc-jit-provider"/> <acronym>GUC</acronym>.
|
linkend="guc-jit-provider"/>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
|
|
|
@ -923,12 +923,12 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
|
||||||
<para>
|
<para>
|
||||||
In the connection URI format, you can list multiple <literal>host:port</literal> pairs
|
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
|
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.
|
common example of this is a host that has both an IPv4 and an IPv6 address.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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
|
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,
|
tried in order, until one succeeds. If none of the hosts can be reached,
|
||||||
the connection fails. If a connection is established successfully, but
|
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
|
multiply their selectivities together to arrive at a much-too-small
|
||||||
row count estimate.
|
row count estimate.
|
||||||
With such statistics, the planner recognizes that the <literal>WHERE</literal>
|
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>
|
</para>
|
||||||
|
|
||||||
</refsect1>
|
</refsect1>
|
||||||
|
|
|
@ -511,7 +511,7 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Show progress report every <replaceable>sec</replaceable> seconds. The report
|
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
|
last report, and the transaction latency average and standard
|
||||||
deviation since the last report. Under throttling (<option>-R</option>),
|
deviation since the last report. Under throttling (<option>-R</option>),
|
||||||
the latency is computed with respect to the transaction scheduled
|
the latency is computed with respect to the transaction scheduled
|
||||||
|
@ -727,9 +727,9 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Remember to take the sampling rate into account when processing the
|
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
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -967,7 +967,7 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
|
||||||
Sets variable <replaceable>varname</replaceable> to a value calculated
|
Sets variable <replaceable>varname</replaceable> to a value calculated
|
||||||
from <replaceable>expression</replaceable>.
|
from <replaceable>expression</replaceable>.
|
||||||
The expression may contain the <literal>NULL</literal> constant,
|
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>,
|
integer constants such as <literal>5432</literal>,
|
||||||
double constants such as <literal>3.14159</literal>,
|
double constants such as <literal>3.14159</literal>,
|
||||||
references to variables <literal>:</literal><replaceable>variablename</replaceable>,
|
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>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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
|
distribution. For <replaceable>parameter</replaceable> in (0, 1), an
|
||||||
approximated algorithm is taken from
|
approximated algorithm is taken from
|
||||||
"Quickly Generating Billion-Record Synthetic Databases",
|
"Quickly Generating Billion-Record Synthetic Databases",
|
||||||
|
|
|
@ -558,7 +558,7 @@ EOF
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Set the field separator for unaligned output to a zero byte. This is
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
|
@ -1233,7 +1233,7 @@ same commits as above
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Specifically, "ldapsearchfilter" allows pattern matching using
|
Specifically, <literal>ldapsearchfilter</literal> allows pattern matching using
|
||||||
combinations of <acronym>LDAP</acronym> attributes.
|
combinations of <acronym>LDAP</acronym> attributes.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
@ -2673,7 +2673,7 @@ same commits as above
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Speed up lookups of builtin function names matching oids (Andres
|
Speed up lookups of built-in function names matching OIDs (Andres
|
||||||
Freund)
|
Freund)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
|
@ -565,7 +565,7 @@ DROP ROLE doomed_role;
|
||||||
<literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
|
<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
|
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
|
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
|
directly and they could be used to gain superuser-level access, therefore care should be taken
|
||||||
when granting these roles to users.
|
when granting these roles to users.
|
||||||
</para>
|
</para>
|
||||||
|
|
Loading…
Reference in New Issue