First-draft release notes for Postgres 9.6.
These are just of beta quality, but we're only at beta ... the section about parallel query, in particular, could doubtless use more work.
This commit is contained in:
parent
a9ba6195f1
commit
c311f78873
|
@ -7575,8 +7575,8 @@
|
|||
be used by software packages that want to interface to
|
||||
<productname>PostgreSQL</> to facilitate finding the required header
|
||||
files and libraries. It provides the same basic information as the
|
||||
<xref linkend="app-pgconfig"> <productname>PostgreSQL</> Client
|
||||
Application.
|
||||
<xref linkend="app-pgconfig"> <productname>PostgreSQL</> client
|
||||
application.
|
||||
</para>
|
||||
|
||||
<table>
|
||||
|
|
|
@ -2012,7 +2012,7 @@ include_dir 'conf.d'
|
|||
number of workers may not actually be available at runtime. If this
|
||||
occurs, the plan will run with fewer workers than expected, which may
|
||||
be inefficient. The default value is 2. Setting this value to 0
|
||||
disables parallel query.
|
||||
disables parallel query execution.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -3657,22 +3657,7 @@ include_dir 'conf.d'
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="parallel-tuple-cost" xreflabel="parallel_tuple_cost">
|
||||
<term><varname>parallel_tuple_cost</varname> (<type>floating point</type>)
|
||||
<indexterm>
|
||||
<primary><varname>parallel_tuple_cost</> configuration parameter</primary>
|
||||
</indexterm>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the planner's estimate of the cost of transferring a tuple
|
||||
from a parallel worker process to another process.
|
||||
The default is 0.1.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="parallel-setup-cost" xreflabel="parallel_setup_cost">
|
||||
<varlistentry id="guc-parallel-setup-cost" xreflabel="parallel_setup_cost">
|
||||
<term><varname>parallel_setup_cost</varname> (<type>floating point</type>)
|
||||
<indexterm>
|
||||
<primary><varname>parallel_setup_cost</> configuration parameter</primary>
|
||||
|
@ -3687,6 +3672,21 @@ include_dir 'conf.d'
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="guc-parallel-tuple-cost" xreflabel="parallel_tuple_cost">
|
||||
<term><varname>parallel_tuple_cost</varname> (<type>floating point</type>)
|
||||
<indexterm>
|
||||
<primary><varname>parallel_tuple_cost</> configuration parameter</primary>
|
||||
</indexterm>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the planner's estimate of the cost of transferring one tuple
|
||||
from a parallel worker process to another process.
|
||||
The default is 0.1.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="guc-effective-cache-size" xreflabel="effective_cache_size">
|
||||
<term><varname>effective_cache_size</varname> (<type>integer</type>)
|
||||
<indexterm>
|
||||
|
@ -4048,8 +4048,8 @@ SELECT * FROM parent WHERE key = 2400;
|
|||
<literal>off</> (use parallel mode only when it is expected to improve
|
||||
performance), <literal>on</> (force parallel query for all queries
|
||||
for which it is thought to be safe), and <literal>regress</> (like
|
||||
on, but with additional behavior changes to facilitate automated
|
||||
regression testing).
|
||||
<literal>on</>, but with additional behavior changes as explained
|
||||
below).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -4067,14 +4067,14 @@ SELECT * FROM parent WHERE key = 2400;
|
|||
|
||||
<para>
|
||||
Setting this value to <literal>regress</> has all of the same effects
|
||||
as setting it to <literal>on</> plus some additional effect that are
|
||||
as setting it to <literal>on</> plus some additional effects that are
|
||||
intended to facilitate automated regression testing. Normally,
|
||||
messages from a parallel worker are prefixed with a context line,
|
||||
but a setting of <literal>regress</> suppresses this to guarantee
|
||||
reproducible results. Also, the <literal>Gather</> nodes added to
|
||||
plans by this setting are hidden from the <literal>EXPLAIN</> output
|
||||
so that the output matches what would be obtained if this setting
|
||||
were turned <literal>off</>.
|
||||
messages from a parallel worker include a context line indicating that,
|
||||
but a setting of <literal>regress</> suppresses this line so that the
|
||||
output is the same as in non-parallel execution. Also,
|
||||
the <literal>Gather</> nodes added to plans by this setting are hidden
|
||||
in <literal>EXPLAIN</> output so that the output matches what
|
||||
would be obtained if this setting were turned <literal>off</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
@ -167,6 +167,7 @@
|
|||
<!ENTITY sourcerepo SYSTEM "sourcerepo.sgml">
|
||||
|
||||
<!ENTITY release SYSTEM "release.sgml">
|
||||
<!ENTITY release-9.6 SYSTEM "release-9.6.sgml">
|
||||
<!ENTITY release-9.5 SYSTEM "release-9.5.sgml">
|
||||
<!ENTITY release-9.4 SYSTEM "release-9.4.sgml">
|
||||
<!ENTITY release-9.3 SYSTEM "release-9.3.sgml">
|
||||
|
|
|
@ -1108,7 +1108,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
|||
(2 rows)
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
|
||||
<table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
|
||||
<title><structname>pg_stat_replication</structname> View</title>
|
||||
<tgroup cols="3">
|
||||
|
@ -2429,7 +2429,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
See <xref linkend="wait-event-table"> for details.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
|
||||
<row>
|
||||
<entry><literal><function>pg_stat_get_backend_wait_event(integer)</function></literal></entry>
|
||||
<entry><type>text</type></entry>
|
||||
|
@ -2524,7 +2524,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
view.
|
||||
</para>
|
||||
|
||||
<table id="pg-stat-progress-vacuum" xreflabel="pg_stat_progress_vacuum">
|
||||
<table id="pg-stat-progress-vacuum-view" xreflabel="pg_stat_progress_vacuum">
|
||||
<title><structname>pg_stat_progress_vacuum</structname> View</title>
|
||||
<tgroup cols="3">
|
||||
<thead>
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -73,6 +73,7 @@ For new features, add links to the documentation sections.
|
|||
The reason for splitting the release notes this way is so that appropriate
|
||||
subsets can easily be copied into back branches.
|
||||
-->
|
||||
&release-9.6;
|
||||
&release-9.5;
|
||||
&release-9.4;
|
||||
&release-9.3;
|
||||
|
|
Loading…
Reference in New Issue