Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Observar 1
Favorito 0
Wiki 捐赠
gooderp18绿色标准版
Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.
Branch: master
Branches Tags
${ item.name }
Criar branch ${ searchTerm }
de master
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/how-parallel-query-works.html

71 linhas
7.0KB
Original Link permanente Anotar Histórico 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>15.1. How Parallel Query Works</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="parallel-query.html" title="Chapter 15. Parallel Query" /><link rel="next" href="when-can-parallel-query-be-used.html" title="15.2. When Can Parallel Query Be Used?" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">15.1. How Parallel Query Works</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="parallel-query.html" title="Chapter 15. Parallel Query">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="parallel-query.html" title="Chapter 15. Parallel Query">Up</a></td><th width="60%" align="center">Chapter 15. Parallel Query</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="when-can-parallel-query-be-used.html" title="15.2. When Can Parallel Query Be Used?">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="HOW-PARALLEL-QUERY-WORKS"><div class="titlepage"><div><div><h2 class="title" style="clear: both">15.1. How Parallel Query Works</h2></div></div></div><p>

  3.     When the optimizer determines that parallel query is the fastest execution

  4.     strategy for a particular query, it will create a query plan which includes

  5.     a <em class="firstterm">Gather</em> or <em class="firstterm">Gather Merge</em>

  6.     node.  Here is a simple example:

  7. 

  8. </p><pre class="screen">

  9. EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';

  10.                                      QUERY PLAN                                      

  11. -------------------------------------------------------------------------------------

  12.  Gather  (cost=1000.00..217018.43 rows=1 width=97)

  13.    Workers Planned: 2

  14.    -&gt;  Parallel Seq Scan on pgbench_accounts  (cost=0.00..216018.33 rows=1 width=97)

  15.          Filter: (filler ~~ '%x%'::text)

  16. (4 rows)

  17. </pre><p>

  18.    </p><p>

  19.     In all cases, the <code class="literal">Gather</code> or

  20.     <code class="literal">Gather Merge</code> node will have exactly one

  21.     child plan, which is the portion of the plan that will be executed in

  22.     parallel.  If the <code class="literal">Gather</code> or <code class="literal">Gather Merge</code> node is

  23.     at the very top of the plan tree, then the entire query will execute in

  24.     parallel.  If it is somewhere else in the plan tree, then only the portion

  25.     of the plan below it will run in parallel.  In the example above, the

  26.     query accesses only one table, so there is only one plan node other than

  27.     the <code class="literal">Gather</code> node itself; since that plan node is a child of the

  28.     <code class="literal">Gather</code> node, it will run in parallel.

  29.    </p><p>

  30.     <a class="link" href="using-explain.html" title="14.1. Using EXPLAIN">Using EXPLAIN</a>, you can see the number of

  31.     workers chosen by the planner.  When the <code class="literal">Gather</code> node is reached

  32.     during query execution, the process which is implementing the user's

  33.     session will request a number of <a class="link" href="bgworker.html" title="Chapter 47. Background Worker Processes">background

  34.     worker processes</a> equal to the number

  35.     of workers chosen by the planner.  The number of background workers that

  36.     the planner will consider using is limited to at most

  37.     <a class="xref" href="runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER">max_parallel_workers_per_gather</a>.  The total number

  38.     of background workers that can exist at any one time is limited by both

  39.     <a class="xref" href="runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES">max_worker_processes</a> and

  40.     <a class="xref" href="runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS">max_parallel_workers</a>.  Therefore, it is possible for a

  41.     parallel query to run with fewer workers than planned, or even with

  42.     no workers at all.  The optimal plan may depend on the number of workers

  43.     that are available, so this can result in poor query performance.  If this

  44.     occurrence is frequent, consider increasing

  45.     <code class="varname">max_worker_processes</code> and <code class="varname">max_parallel_workers</code>

  46.     so that more workers can be run simultaneously or alternatively reducing

  47.     <code class="varname">max_parallel_workers_per_gather</code> so that the planner

  48.     requests fewer workers.

  49.    </p><p>

  50.     Every background worker process which is successfully started for a given

  51.     parallel query will execute the parallel portion of the plan.  The leader

  52.     will also execute that portion of the plan, but it has an additional

  53.     responsibility: it must also read all of the tuples generated by the

  54.     workers.  When the parallel portion of the plan generates only a small

  55.     number of tuples, the leader will often behave very much like an additional

  56.     worker, speeding up query execution.  Conversely, when the parallel portion

  57.     of the plan generates a large number of tuples, the leader may be almost

  58.     entirely occupied with reading the tuples generated by the workers and

  59.     performing any further processing steps which are required by plan nodes

  60.     above the level of the <code class="literal">Gather</code> node or

  61.     <code class="literal">Gather Merge</code> node.  In such cases, the leader will

  62.     do very little of the work of executing the parallel portion of the plan.

  63.    </p><p>

  64.     When the node at the top of the parallel portion of the plan is

  65.     <code class="literal">Gather Merge</code> rather than <code class="literal">Gather</code>, it indicates that

  66.     each process executing the parallel portion of the plan is producing

  67.     tuples in sorted order, and that the leader is performing an

  68.     order-preserving merge.  In contrast, <code class="literal">Gather</code> reads tuples

  69.     from the workers in whatever order is convenient, destroying any sort

  70.     order that may have existed.

  71.    </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="parallel-query.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel-query.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="when-can-parallel-query-be-used.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 15. Parallel Query </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 15.2. When Can Parallel Query Be Used?</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1