database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Add parallel_leader_participation GUC.

Browse Source 
Sometimes, for testing, it's useful to have the leader do nothing but
read tuples from workers; and it's possible that could work out better
even in production.

Thomas Munro, reviewed by Amit Kapila and by me.  A few final tweaks
by me.

Discussion: http://postgr.es/m/CAEepm=2U++Lp3bNTv2Bv_kkr5NE2pOyHhxU=G0YTa4ZhSYhHiw@mail.gmail.com
This commit is contained in:
Robert Haas
2017-11-15 08:17:29 -05:00
parent 7518049980
commit e5253fdc4f
10 changed files with 205 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -4265,6 +4265,32 @@ SELECT * FROM parent WHERE key = 2400;
</listitem>
</varlistentry>
<varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
<term>
<varname>parallel_leader_participation</varname> (<type>boolean</type>)
<indexterm>
<primary>
<varname>parallel_leader_participation</varname> configuration
parameter
</primary>
</indexterm>
</term>
<listitem>
<para>
Allows the leader process to execute the query plan under
<literal>Gather</literal> and <literal>Gather Merge</literal> nodes
instead of waiting for worker processes. The default is
<literal>on</literal>. Setting this value to <literal>off</literal>
reduces the likelihood that workers will become blocked because the
leader is not reading tuples fast enough, but requires the leader
process to wait for worker processes to start up before the first
tuples can be produced. The degree to which the leader can help or
hinder performance depends on the plan type, number of workers and
query duration.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-force-parallel-mode" xreflabel="force_parallel_mode">
<term><varname>force_parallel_mode</varname> (<type>enum</type>)
<indexterm>