8000 Assorted documentation improvements for max_parallel_workers. · postgres/postgres@0e50af2 · GitHub
[go: up one dir, main page]

Skip to content
  • Commit 0e50af2

    Browse files
    committed
    Assorted documentation improvements for max_parallel_workers.
    Commit b460f5d overlooked a few bits of documentation that seem like they should mention the new setting.
    1 parent 2b959d4 commit 0e50af2

    File tree

    2 files changed

    +23
    -4
    lines changed

    2 files changed

    +23
    -4
    lines changed

    doc/src/sgml/config.sgml

    Lines changed: 10 additions & 0 deletions
    Original file line numberDiff line numberDiff line change
    @@ -1990,6 +1990,12 @@ include_dir 'conf.d'
    19901990
    same or higher value than on the master server. Otherwise, queries
    19911991
    will not be allowed in the standby server.
    19921992
    </para>
    1993+
    1994+
    <para>
    1995+
    When changing this value, consider also adjusting
    1996+
    <xref linkend="guc-max-parallel-workers"> and
    1997+
    <xref linkend="guc-max-parallel-workers-per-gather">.
    1998+
    </para>
    19931999
    </listitem>
    19942000
    </varlistentry>
    19952001

    @@ -2047,6 +2053,10 @@ include_dir 'conf.d'
    20472053
    parallel queries. The default value is 8. When increasing or
    20482054
    decreasing this value, consider also adjusting
    20492055
    <xref linkend="guc-max-parallel-workers-per-gather">.
    2056+
    Also, note that a setting for this value which is higher than
    2057+
    <xref linkend="guc-max-worker-processes"> will have no effect,
    2058+
    since parallel workers are taken from the pool of worker processes
    2059+
    established by that setting.
    20502060
    </para>
    20512061
    </listitem>
    20522062
    </varlistentry>

    doc/src/sgml/parallel.sgml

    Lines changed: 13 additions & 4 deletions
    Original file line numberDiff line numberDiff line change
    @@ -61,14 +61,15 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
    6161
    session will request a number of <link linkend="bgworker">background
    6262
    worker processes</link> equal to the number
    6363
    of workers chosen by the planner. The total number of background
    64-
    workers that can exist at any one time is limited by
    65-
    <xref linkend="guc-max-worker-processes">, so it is possible for a
    64+
    workers that can exist at any one time is limited by both
    65+
    <xref linkend="guc-max-worker-processes"> and
    66+
    <xref linkend="guc-max-parallel-workers">, so it is possible for a
    6667
    parallel query to run with fewer workers than planned, or even with
    6768
    no workers at all. The optimal plan may depend on the number of workers
    6869
    that are available, so this can result in poor query performance. If this
    6970
    occurrence is frequent, considering increasing
    70-
    <varname>max_worker_processes</> so that more workers can be run
    71-
    simultaneously or alternatively reducing
    71+
    <varname>max_worker_processes</> and <varname>max_parallel_workers</>
    72+
    so that more workers can be run simultaneously or alternatively reducing
    7273
    <xref linkend="guc-max-parallel-workers-per-gather"> so that the planner
    7374
    requests fewer workers.
    7475
    </para>
    @@ -203,6 +204,14 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
    203204
    </para>
    204205
    </listitem>
    205206

    207+
    <listitem>
    208+
    <para>
    209+
    No background workers can be obtained because of the limitation that
    210+
    the total number of background workers launched for purposes of
    211+
    parallel query cannot exceed <xref linkend="guc-max-parallel-workers">.
    212+
    </para>
    213+
    </listitem>
    214+
    206215
    <listitem>
    207216
    <para>
    208217
    The client sends an Execute message with a non-zero fetch count.

    0 commit comments

    Comments
     (0)
    0