<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>How Parallel Query Works</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.6.22 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Parallel Query"
HREF="parallel-query.html"><LINK
REL="PREVIOUS"
TITLE="Parallel Query"
HREF="parallel-query.html"><LINK
REL="NEXT"
TITLE="When Can Parallel Query Be Used?"
HREF="when-can-parallel-query-be-used.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2021-05-18T09:16:10"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="4"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.6.22 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Parallel Query"
HREF="parallel-query.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="parallel-query.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 15. Parallel Query</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="When Can Parallel Query Be Used?"
HREF="when-can-parallel-query-be-used.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="HOW-PARALLEL-QUERY-WORKS"
>15.1. How Parallel Query Works</A
></H1
><P
> When the optimizer determines that parallel query is the fastest execution
strategy for a particular query, it will create a query plan which includes
a <I
CLASS="FIRSTTERM"
>Gather node</I
>. Here is a simple example:
</P><PRE
CLASS="SCREEN"
>EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
QUERY PLAN
-------------------------------------------------------------------------------------
Gather (cost=1000.00..217018.43 rows=1 width=97)
Workers Planned: 2
-> Parallel Seq Scan on pgbench_accounts (cost=0.00..216018.33 rows=1 width=97)
Filter: (filler ~~ '%x%'::text)
(4 rows)</PRE
><P>
</P
><P
> In all cases, the <TT
CLASS="LITERAL"
>Gather</TT
> node will have exactly one
child plan, which is the portion of the plan that will be executed in
parallel. If the <TT
CLASS="LITERAL"
>Gather</TT
> node is at the very top of the plan
tree, then the entire query will execute in parallel. If it is somewhere
else in the plan tree, then only that portion of the query will run in
parallel. In the example above, the query accesses only one table, so
there is only one plan node other than the <TT
CLASS="LITERAL"
>Gather</TT
> node itself;
since that plan node is a child of the <TT
CLASS="LITERAL"
>Gather</TT
> node, it will
run in parallel.
</P
><P
> <A
HREF="using-explain.html"
>Using EXPLAIN</A
>, you can see the number of
workers chosen by the planner. When the <TT
CLASS="LITERAL"
>Gather</TT
> node is reached
during query execution, the process which is implementing the user's
session will request a number of <A
HREF="bgworker.html"
>background
worker processes</A
> equal to the number
of workers chosen by the planner. The total number of background
workers that can exist at any one time is limited by
<A
HREF="runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES"
>max_worker_processes</A
>, so it is possible for a
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
that are available, so this can result in poor query performance. If this
occurrence is frequent, considering increasing
<TT
CLASS="VARNAME"
>max_worker_processes</TT
> so that more workers can be run
simultaneously or alternatively reducing
<A
HREF="runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER"
>max_parallel_workers_per_gather</A
> so that the planner
requests fewer workers.
</P
><P
> Every background worker process which is successfully started for a given
parallel query will execute the portion of the plan which is a descendent
of the <TT
CLASS="LITERAL"
>Gather</TT
> node. The leader will also execute that portion
of the plan, but it has an additional responsibility: it must also read
all of the tuples generated by the workers. When the parallel portion of
the plan generates only a small number of tuples, the leader will often
behave very much like an additional worker, speeding up query execution.
Conversely, when the parallel portion of the plan generates a large number
of tuples, the leader may be almost entirely occupied with reading the
tuples generated by the workers and performing any further processing
steps which are required by plan nodes above the level of the
<TT
CLASS="LITERAL"
>Gather</TT
> node. In such cases, the leader will do very
little of the work of executing the parallel portion of the plan.
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="parallel-query.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="when-can-parallel-query-be-used.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Parallel Query</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="parallel-query.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>When Can Parallel Query Be Used?</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
distrib
>
Mageia
>
7
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
5fea23694c765462b86d6ddf74461eab
>
files
>
339
