Sophie: postgresql9.6-docs-9.6.22-1.mga7 noarch

postgresql9.6-docs-9.6.22-1.mga7.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Parallel Plans</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="When Can Parallel Query Be Used?"
HREF="when-can-parallel-query-be-used.html"><LINK
REL="NEXT"
TITLE="Parallel Safety"
HREF="parallel-safety.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="When Can Parallel Query Be Used?"
HREF="when-can-parallel-query-be-used.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="Parallel Safety"
HREF="parallel-safety.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PARALLEL-PLANS"
>15.3. Parallel Plans</A
></H1
><P
>    Because each worker executes the parallel portion of the plan to
    completion, it is not possible to simply take an ordinary query plan
    and run it using multiple workers.  Each worker would produce a full
    copy of the output result set, so the query would not run any faster
    than normal but would produce incorrect results.  Instead, the parallel
    portion of the plan must be what is known internally to the query
    optimizer as a <I
CLASS="FIRSTTERM"
>partial plan</I
>; that is, it must be constructed
    so that each process which executes the plan will generate only a
    subset of the output rows in such a way that each required output row
    is guaranteed to be generated by exactly one of the cooperating processes.
  </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PARALLEL-SCANS"
>15.3.1. Parallel Scans</A
></H2
><P
>    Currently, the only type of scan which has been modified to work with
    parallel query is a sequential scan.  Therefore, the driving table in
    a parallel plan will always be scanned using a
    <TT
CLASS="LITERAL"
>Parallel Seq Scan</TT
>.  The relation's blocks will be divided
    among the cooperating processes.  Blocks are handed out one at a
    time, so that access to the relation remains sequential.  Each process
    will visit every tuple on the page assigned to it before requesting a new
    page.
  </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PARALLEL-JOINS"
>15.3.2. Parallel Joins</A
></H2
><P
>    The driving table may be joined to one or more other tables using nested
    loops or hash joins.  The inner side of the join may be any kind of
    non-parallel plan that is otherwise supported by the planner provided that
    it is safe to run within a parallel worker.  For example, it may be an
    index scan which looks up a value taken from the outer side of the join.
    Each worker will execute the inner side of the join in full,  which for
    hash join means that an identical hash table is built in each worker
    process.
  </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PARALLEL-AGGREGATION"
>15.3.3. Parallel Aggregation</A
></H2
><P
>    <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> supports parallel aggregation by aggregating in
    two stages.  First, each process participating in the parallel portion of
    the query performs an aggregation step, producing a partial result for
    each group of which that process is aware.  This is reflected in the plan
    as a <TT
CLASS="LITERAL"
>Partial Aggregate</TT
> node.  Second, the partial results are
    transferred to the leader via the <TT
CLASS="LITERAL"
>Gather</TT
> node.  Finally, the
    leader re-aggregates the results across all workers in order to produce
    the final result.  This is reflected in the plan as a
    <TT
CLASS="LITERAL"
>Finalize Aggregate</TT
> node.
  </P
><P
>    Because the <TT
CLASS="LITERAL"
>Finalize Aggregate</TT
> node runs on the leader
    process, queries which produce a relatively large number of groups in
    comparison to the number of input rows will appear less favorable to the
    query planner. For example, in the worst-case scenario the number of
    groups seen by the <TT
CLASS="LITERAL"
>Finalize Aggregate</TT
> node could be as many as
    the number of input rows which were seen by all worker processes in the
    <TT
CLASS="LITERAL"
>Partial Aggregate</TT
> stage. For such cases, there is clearly
    going to be no performance benefit to using parallel aggregation. The
    query planner takes this into account during the planning process and is
    unlikely to choose parallel aggregate in this scenario.
  </P
><P
>    Parallel aggregation is not supported in all situations.  Each aggregate
    must be <A
HREF="parallel-safety.html"
>safe</A
> for parallelism and must
    have a combine function.  If the aggregate has a transition state of type
    <TT
CLASS="LITERAL"
>internal</TT
>, it must have serialization and deserialization
    functions.  See <A
HREF="sql-createaggregate.html"
>CREATE AGGREGATE</A
> for more details.
    Parallel aggregation is not supported if any aggregate function call
    contains <TT
CLASS="LITERAL"
>DISTINCT</TT
> or <TT
CLASS="LITERAL"
>ORDER BY</TT
> clause and is also
    not supported for ordered set aggregates or when  the query involves
    <TT
CLASS="LITERAL"
>GROUPING SETS</TT
>.  It can only be used when all joins involved in
    the query are also part of the parallel portion of the plan.
  </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PARALLEL-PLAN-TIPS"
>15.3.4. Parallel Plan Tips</A
></H2
><P
>    If a query that is expected to do so does not produce a parallel plan,
    you can try reducing <A
HREF="runtime-config-query.html#GUC-PARALLEL-SETUP-COST"
>parallel_setup_cost</A
> or
    <A
HREF="runtime-config-query.html#GUC-PARALLEL-TUPLE-COST"
>parallel_tuple_cost</A
>.  Of course, this plan may turn
    out to be slower than the serial plan which the planner preferred, but
    this will not always be the case.  If you don't get a parallel
    plan even with very small values of these settings (e.g., after setting
    them both to zero), there may be some reason why the query planner is
    unable to generate a parallel plan for your query.  See
    <A
HREF="when-can-parallel-query-be-used.html"
>Section 15.2</A
> and
    <A
HREF="parallel-safety.html"
>Section 15.4</A
> for information on why this may be
    the case.
  </P
><P
>    When executing a parallel plan, you can use <TT
CLASS="LITERAL"
>EXPLAIN (ANALYZE,
    VERBOSE)</TT
> to display per-worker statistics for each plan node.
    This may be useful in determining whether the work is being evenly
    distributed between all plan nodes and more generally in understanding the
    performance characteristics of the plan.
  </P
></DIV
></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="when-can-parallel-query-be-used.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="parallel-safety.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>When Can Parallel Query Be Used?</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"
>Parallel Safety</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>