I wrote: > I really think that a GUC named "max_parallel_workers", which in fact > limits the number of workers and not something else, is the way to go.
To be concrete, I suggest comparing the attached documentation patch with Robert's. Which one is more understandable? (I have not bothered preparing code changes to go with this, but am willing to do so.) regards, tom lane
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 72b5920..fccde28 100644 *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *************** include_dir 'conf.d' *** 1998,2019 **** </listitem> </varlistentry> ! <varlistentry id="guc-max-parallel-degree" xreflabel="max_parallel_degree"> ! <term><varname>max_parallel_degree</varname> (<type>integer</type>) <indexterm> ! <primary><varname>max_parallel_degree</> configuration parameter</primary> </indexterm> </term> <listitem> <para> ! Sets the maximum number of workers that can be started for an ! individual parallel operation. Parallel workers are taken from the ! pool of processes established by ! <xref linkend="guc-max-worker-processes">. Note that the requested ! 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 execution. </para> </listitem> </varlistentry> --- 1998,2020 ---- </listitem> </varlistentry> ! <varlistentry id="guc-max-parallel-workers" xreflabel="max_parallel_workers"> ! <term><varname>max_parallel_workers</varname> (<type>integer</type>) <indexterm> ! <primary><varname>max_parallel_workers</> configuration parameter</primary> </indexterm> </term> <listitem> <para> ! Sets the maximum number of worker processes that can be used to ! assist an individual parallelizable operation. Parallel workers are ! taken from the cluster-wide pool of processes established by ! <xref linkend="guc-max-worker-processes">. Depending on the size of ! the pool and the number of other parallel queries active, the ! requested 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 execution. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index d1807ed..d73cf39 100644 *** a/doc/src/sgml/ref/create_table.sgml --- b/doc/src/sgml/ref/create_table.sgml *************** CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY *** 909,922 **** </varlistentry> <varlistentry> ! <term><literal>parallel_degree</> (<type>integer</>)</term> <listitem> <para> ! The parallel degree for a table is the number of workers that should ! be used to assist a parallel scan of that table. If not set, the ! system will determine a value based on the relation size. The actual ! number of workers chosen by the planner may be less, for example due to ! the setting of <xref linkend="guc-max-parallel-degree">. </para> </listitem> </varlistentry> --- 909,923 ---- </varlistentry> <varlistentry> ! <term><literal>parallel_workers</> (<type>integer</>)</term> <listitem> <para> ! This setting limits the number of parallel worker processes that should ! be used to assist a parallel scan of this table. If not set, the ! planner will select a value based on the relation size. The actual ! number of workers chosen by the planner may be less, for example ! because it is also constrained by ! <xref linkend="guc-max-parallel-workers">; it will not be more. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml index 38e1967..3d78b00 100644 *** a/doc/src/sgml/release-9.6.sgml --- b/doc/src/sgml/release-9.6.sgml *************** *** 153,159 **** <para> Use of parallel query execution can be controlled through the new configuration parameters ! <xref linkend="guc-max-parallel-degree">, <xref linkend="guc-force-parallel-mode">, <xref linkend="guc-parallel-setup-cost">, and <xref linkend="guc-parallel-tuple-cost">. --- 153,159 ---- <para> Use of parallel query execution can be controlled through the new configuration parameters ! <xref linkend="guc-max-parallel-workers">, <xref linkend="guc-force-parallel-mode">, <xref linkend="guc-parallel-setup-cost">, and <xref linkend="guc-parallel-tuple-cost">.
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers