Fix whitespace
This commit is contained in:
parent
6d69ea3318
commit
aa14bc41d1
|
@ -20,8 +20,8 @@
|
||||||
The implementation of a
|
The implementation of a
|
||||||
<ulink url="http://en.wikipedia.org/wiki/Bloom_filter">Bloom filter</ulink>
|
<ulink url="http://en.wikipedia.org/wiki/Bloom_filter">Bloom filter</ulink>
|
||||||
allows fast exclusion of non-candidate tuples via signatures.
|
allows fast exclusion of non-candidate tuples via signatures.
|
||||||
Since a signature is a lossy representation of all indexed attributes,
|
Since a signature is a lossy representation of all indexed attributes,
|
||||||
search results must be rechecked using heap information.
|
search results must be rechecked using heap information.
|
||||||
The user can specify signature length (in uint16, default is 5) and the
|
The user can specify signature length (in uint16, default is 5) and the
|
||||||
number of bits, which can be set per attribute (1 < colN < 2048).
|
number of bits, which can be set per attribute (1 < colN < 2048).
|
||||||
</para>
|
</para>
|
||||||
|
@ -33,7 +33,7 @@
|
||||||
possible queries where one needs only a single bloom index. A Bloom index
|
possible queries where one needs only a single bloom index. A Bloom index
|
||||||
supports only equality comparison. Since it's a signature file, and not a
|
supports only equality comparison. Since it's a signature file, and not a
|
||||||
tree, it always must be read fully, but sequentially, so that index search
|
tree, it always must be read fully, but sequentially, so that index search
|
||||||
performance is constant and doesn't depend on a query.
|
performance is constant and doesn't depend on a query.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|
|
@ -820,7 +820,7 @@ IterateDirectModify (ForeignScanState *node);
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Whether the query has the clause or not, the query's reported row count
|
Whether the query has the clause or not, the query's reported row count
|
||||||
must be incremented by the FDW itself. When the query doesn't have the
|
must be incremented by the FDW itself. When the query doesn't have the
|
||||||
clause, the FDW must also increment the row count for the
|
clause, the FDW must also increment the row count for the
|
||||||
<structname>ForeignScanState</> node in the <command>EXPLAIN ANALYZE</>
|
<structname>ForeignScanState</> node in the <command>EXPLAIN ANALYZE</>
|
||||||
|
|
|
@ -734,7 +734,7 @@
|
||||||
from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
|
from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
|
||||||
<acronym>GIN</> is capable of postponing much of this work by inserting
|
<acronym>GIN</> is capable of postponing much of this work by inserting
|
||||||
new tuples into a temporary, unsorted list of pending entries.
|
new tuples into a temporary, unsorted list of pending entries.
|
||||||
When the table is vacuumed or autoanalyzed, or when
|
When the table is vacuumed or autoanalyzed, or when
|
||||||
<function>gin_clean_pending_list</function> function is called, or if the
|
<function>gin_clean_pending_list</function> function is called, or if the
|
||||||
pending list becomes larger than
|
pending list becomes larger than
|
||||||
<xref linkend="guc-gin-pending-list-limit">, the entries are moved to the
|
<xref linkend="guc-gin-pending-list-limit">, the entries are moved to the
|
||||||
|
|
|
@ -563,7 +563,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
|
||||||
<command>VACUUM</> normally only scans pages that have been modified
|
<command>VACUUM</> normally only scans pages that have been modified
|
||||||
since the last vacuum, but <structfield>relfrozenxid</> can only be
|
since the last vacuum, but <structfield>relfrozenxid</> can only be
|
||||||
advanced when every page of the table
|
advanced when every page of the table
|
||||||
that might contain unfrozen XIDs is scanned. This happens when
|
that might contain unfrozen XIDs is scanned. This happens when
|
||||||
<structfield>relfrozenxid</> is more than
|
<structfield>relfrozenxid</> is more than
|
||||||
<varname>vacuum_freeze_table_age</> transactions old, when
|
<varname>vacuum_freeze_table_age</> transactions old, when
|
||||||
<command>VACUUM</>'s <literal>FREEZE</> option is used, or when all
|
<command>VACUUM</>'s <literal>FREEZE</> option is used, or when all
|
||||||
|
|
|
@ -304,7 +304,7 @@
|
||||||
<term><literal>fetch_size</literal></term>
|
<term><literal>fetch_size</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This option specifies the number of rows <filename>postgres_fdw</>
|
This option specifies the number of rows <filename>postgres_fdw</>
|
||||||
should get in each fetch operation. It can be specified for a foreign
|
should get in each fetch operation. It can be specified for a foreign
|
||||||
table or a foreign server. The option specified on a table overrides
|
table or a foreign server. The option specified on a table overrides
|
||||||
an option specified for the server.
|
an option specified for the server.
|
||||||
|
|
|
@ -71,7 +71,7 @@ PostgreSQL documentation
|
||||||
missing files from a WAL archive automatically is currently not supported.
|
missing files from a WAL archive automatically is currently not supported.
|
||||||
Besides, <application>pg_rewind</> use cases are not limited by failover.
|
Besides, <application>pg_rewind</> use cases are not limited by failover.
|
||||||
For instance, standby server could be promoted, run some writes and
|
For instance, standby server could be promoted, run some writes and
|
||||||
then be returned back as standby.
|
then be returned back as standby.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -134,8 +134,8 @@ PostgreSQL documentation
|
||||||
<para>
|
<para>
|
||||||
Specifies a libpq connection string to connect to the source
|
Specifies a libpq connection string to connect to the source
|
||||||
<productname>PostgreSQL</> server to synchronize the target with.
|
<productname>PostgreSQL</> server to synchronize the target with.
|
||||||
The connection must be a normal (non-replication) connection
|
The connection must be a normal (non-replication) connection
|
||||||
with superuser access. The server must be up and running,
|
with superuser access. The server must be up and running,
|
||||||
and must not be in recovery mode.
|
and must not be in recovery mode.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
|
@ -1064,8 +1064,8 @@ f(x) = exp(-parameter * (x - min) / (max - min + 1)) / (1 - exp(-parameter))
|
||||||
function of the standard normal distribution, with mean <literal>mu</>
|
function of the standard normal distribution, with mean <literal>mu</>
|
||||||
defined as <literal>(max + min) / 2.0</>, with
|
defined as <literal>(max + min) / 2.0</>, with
|
||||||
<literallayout>
|
<literallayout>
|
||||||
f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
|
f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
|
||||||
(2.0 * PHI(parameter) - 1)
|
(2.0 * PHI(parameter) - 1)
|
||||||
</literallayout>
|
</literallayout>
|
||||||
then value <replaceable>i</> between <replaceable>min</> and
|
then value <replaceable>i</> between <replaceable>min</> and
|
||||||
<replaceable>max</> inclusive is drawn with probability:
|
<replaceable>max</> inclusive is drawn with probability:
|
||||||
|
@ -1158,22 +1158,22 @@ END;
|
||||||
<para>
|
<para>
|
||||||
Here is a snippet of the log file generated:
|
Here is a snippet of the log file generated:
|
||||||
<screen>
|
<screen>
|
||||||
0 199 2241 0 1175850568 995598
|
0 199 2241 0 1175850568 995598
|
||||||
0 200 2465 0 1175850568 998079
|
0 200 2465 0 1175850568 998079
|
||||||
0 201 2513 0 1175850569 608
|
0 201 2513 0 1175850569 608
|
||||||
0 202 2038 0 1175850569 2663
|
0 202 2038 0 1175850569 2663
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
Another example with --rate=100 and --latency-limit=5 (note the additional
|
Another example with --rate=100 and --latency-limit=5 (note the additional
|
||||||
<replaceable>schedule_lag</> column):
|
<replaceable>schedule_lag</> column):
|
||||||
<screen>
|
<screen>
|
||||||
0 81 4621 0 1412881037 912698 3005
|
0 81 4621 0 1412881037 912698 3005
|
||||||
0 82 6173 0 1412881037 914578 4304
|
0 82 6173 0 1412881037 914578 4304
|
||||||
0 83 skipped 0 1412881037 914578 5217
|
0 83 skipped 0 1412881037 914578 5217
|
||||||
0 83 skipped 0 1412881037 914578 5099
|
0 83 skipped 0 1412881037 914578 5099
|
||||||
0 83 4722 0 1412881037 916203 3108
|
0 83 4722 0 1412881037 916203 3108
|
||||||
0 84 4142 0 1412881037 918023 2333
|
0 84 4142 0 1412881037 918023 2333
|
||||||
0 85 2465 0 1412881037 919759 740
|
0 85 2465 0 1412881037 919759 740
|
||||||
</screen>
|
</screen>
|
||||||
In this example, transaction 82 was late, because its latency (6.173 ms) was
|
In this example, transaction 82 was late, because its latency (6.173 ms) was
|
||||||
over the 5 ms limit. The next two transactions were skipped, because they
|
over the 5 ms limit. The next two transactions were skipped, because they
|
||||||
|
|
|
@ -99,11 +99,11 @@ Testing timing overhead for 3 seconds.
|
||||||
Per loop time including overhead: 35.96 nsec
|
Per loop time including overhead: 35.96 nsec
|
||||||
Histogram of timing durations:
|
Histogram of timing durations:
|
||||||
< usec % of total count
|
< usec % of total count
|
||||||
1 96.40465 80435604
|
1 96.40465 80435604
|
||||||
2 3.59518 2999652
|
2 3.59518 2999652
|
||||||
4 0.00015 126
|
4 0.00015 126
|
||||||
8 0.00002 13
|
8 0.00002 13
|
||||||
16 0.00000 2
|
16 0.00000 2
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -160,11 +160,11 @@ tsc hpet acpi_pm
|
||||||
Per loop time including overhead: 722.92 nsec
|
Per loop time including overhead: 722.92 nsec
|
||||||
Histogram of timing durations:
|
Histogram of timing durations:
|
||||||
< usec % of total count
|
< usec % of total count
|
||||||
1 27.84870 1155682
|
1 27.84870 1155682
|
||||||
2 72.05956 2990371
|
2 72.05956 2990371
|
||||||
4 0.07810 3241
|
4 0.07810 3241
|
||||||
8 0.01357 563
|
8 0.01357 563
|
||||||
16 0.00007 3
|
16 0.00007 3
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -212,12 +212,12 @@ Testing timing overhead for 3 seconds.
|
||||||
Per timing duration including loop overhead: 97.75 ns
|
Per timing duration including loop overhead: 97.75 ns
|
||||||
Histogram of timing durations:
|
Histogram of timing durations:
|
||||||
< usec % of total count
|
< usec % of total count
|
||||||
1 90.23734 27694571
|
1 90.23734 27694571
|
||||||
2 9.75277 2993204
|
2 9.75277 2993204
|
||||||
4 0.00981 3010
|
4 0.00981 3010
|
||||||
8 0.00007 22
|
8 0.00007 22
|
||||||
16 0.00000 1
|
16 0.00000 1
|
||||||
32 0.00000 1
|
32 0.00000 1
|
||||||
</screen></para>
|
</screen></para>
|
||||||
|
|
||||||
</refsect2>
|
</refsect2>
|
||||||
|
|
|
@ -637,7 +637,7 @@ typedef struct spgInnerConsistentOut
|
||||||
responsible for palloc'ing the
|
responsible for palloc'ing the
|
||||||
<structfield>nodeNumbers</>, <structfield>levelAdds</> and
|
<structfield>nodeNumbers</>, <structfield>levelAdds</> and
|
||||||
<structfield>reconstructedValues</> arrays.
|
<structfield>reconstructedValues</> arrays.
|
||||||
Sometimes accumulating some information is needed, while
|
Sometimes accumulating some information is needed, while
|
||||||
descending from parent to child node was happened. In this case
|
descending from parent to child node was happened. In this case
|
||||||
<structfield>traversalValues</> array keeps pointers to
|
<structfield>traversalValues</> array keeps pointers to
|
||||||
specific data you need to accumulate for every child node.
|
specific data you need to accumulate for every child node.
|
||||||
|
|
Loading…
Reference in New Issue