1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Assorted documentation improvements for max_parallel_workers.

Browse Source 
Commit b460f5d6693103076dc554aa7cbb96e1e53074f9 overlooked a few bits
of documentation that seem like they should mention the new setting.
This commit is contained in:
Robert Haas 2016-12-05 11:03:17 -05:00
parent 2b959d4957
commit 0e50af2453
2 changed files with 23 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/sgml/config.sgml
View File

@ -1990,6 +1990,12 @@ include_dir 'conf.d'
same or higher value than on the master server. Otherwise, queries same or higher value than on the master server. Otherwise, queries
will not be allowed in the standby server. will not be allowed in the standby server.
</para> </para>
<para>
When changing this value, consider also adjusting
<xref linkend="guc-max-parallel-workers"> and
<xref linkend="guc-max-parallel-workers-per-gather">.
</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -2047,6 +2053,10 @@ include_dir 'conf.d'
parallel queries. The default value is 8. When increasing or parallel queries. The default value is 8. When increasing or
decreasing this value, consider also adjusting decreasing this value, consider also adjusting
<xref linkend="guc-max-parallel-workers-per-gather">. <xref linkend="guc-max-parallel-workers-per-gather">.
Also, note that a setting for this value which is higher than
<xref linkend="guc-max-worker-processes"> will have no effect,
since parallel workers are taken from the pool of worker processes
established by that setting.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>

17
doc/src/sgml/parallel.sgml
View File

@ -61,14 +61,15 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
session will request a number of <link linkend="bgworker">background session will request a number of <link linkend="bgworker">background
worker processes</link> equal to the number worker processes</link> equal to the number
of workers chosen by the planner. The total number of background of workers chosen by the planner. The total number of background
workers that can exist at any one time is limited by workers that can exist at any one time is limited by both
<xref linkend="guc-max-worker-processes">, so it is possible for a <xref linkend="guc-max-worker-processes"> and
<xref linkend="guc-max-parallel-workers">, so it is possible for a
parallel query to run with fewer workers than planned, or even with parallel query to run with fewer workers than planned, or even with
no workers at all. The optimal plan may depend on the number of workers no workers at all. The optimal plan may depend on the number of workers
that are available, so this can result in poor query performance. If this that are available, so this can result in poor query performance. If this
occurrence is frequent, considering increasing occurrence is frequent, considering increasing
<varname>max_worker_processes</> so that more workers can be run <varname>max_worker_processes</> and <varname>max_parallel_workers</>
simultaneously or alternatively reducing so that more workers can be run simultaneously or alternatively reducing
<xref linkend="guc-max-parallel-workers-per-gather"> so that the planner <xref linkend="guc-max-parallel-workers-per-gather"> so that the planner
requests fewer workers. requests fewer workers.
</para> </para>
@ -203,6 +204,14 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
</para> </para>
</listitem> </listitem>
<listitem>
<para>
No background workers can be obtained because of the limitation that
the total number of background workers launched for purposes of
parallel query cannot exceed <xref linkend="guc-max-parallel-workers">.
</para>
</listitem>
<listitem> <listitem>
<para> <para>
The client sends an Execute message with a non-zero fetch count. The client sends an Execute message with a non-zero fetch count.