Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Наблюдаван 1
Харесван 0
Уики 捐赠
gooderp18绿色标准版
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Клон: master
Клонове Маркери
${ item.name }
Create branch ${ searchTerm }
от 'master'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/runtime-config-query.html

553 lines
42KB
Директен файл Постоянна връзка Blame История 

  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>19.7. Query Planning</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="runtime-config-replication.html" title="19.6. Replication" /><link rel="next" href="runtime-config-logging.html" title="19.8. Error Reporting and Logging" /></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">19.7. Query Planning</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-replication.html" title="19.6. Replication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 19. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 19. Server Configuration</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="runtime-config-logging.html" title="19.8. Error Reporting and Logging">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="RUNTIME-CONFIG-QUERY"><div class="titlepage"><div><div><h2 class="title" style="clear: both">19.7. Query Planning</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-ENABLE">19.7.1. Planner Method Configuration</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS">19.7.2. Planner Cost Constants</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO">19.7.3. Genetic Query Optimizer</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER">19.7.4. Other Planner Options</a></span></dt></dl></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-ENABLE"><div class="titlepage"><div><div><h3 class="title">19.7.1. Planner Method Configuration</h3></div></div></div><p>

  3.        These configuration parameters provide a crude method of

  4.        influencing the query plans chosen by the query optimizer. If

  5.        the default plan chosen by the optimizer for a particular query

  6.        is not optimal, a <span class="emphasis"><em>temporary</em></span> solution is to use one

  7.        of these configuration parameters to force the optimizer to

  8.        choose a different plan.

  9.        Better ways to improve the quality of the

  10.        plans chosen by the optimizer include adjusting the planner cost

  11.        constants (see <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS" title="19.7.2. Planner Cost Constants">Section 19.7.2</a>),

  12.        running <a class="xref" href="sql-analyze.html" title="ANALYZE"><span class="refentrytitle">ANALYZE</span></a> manually, increasing

  13.        the value of the <a class="xref" href="runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET">default_statistics_target</a> configuration parameter,

  14.        and increasing the amount of statistics collected for

  15.        specific columns using <code class="command">ALTER TABLE SET

  16.        STATISTICS</code>.

  17.       </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-ENABLE-BITMAPSCAN"><span class="term"><code class="varname">enable_bitmapscan</code> (<code class="type">boolean</code>)

  18.       <a id="id-1.6.6.10.2.3.1.1.3" class="indexterm"></a>

  19.       <a id="id-1.6.6.10.2.3.1.1.4" class="indexterm"></a>

  20.       </span></dt><dd><p>

  21.         Enables or disables the query planner's use of bitmap-scan plan

  22.         types. The default is <code class="literal">on</code>.

  23.        </p></dd><dt id="GUC-ENABLE-GATHERMERGE"><span class="term"><code class="varname">enable_gathermerge</code> (<code class="type">boolean</code>)

  24.       <a id="id-1.6.6.10.2.3.2.1.3" class="indexterm"></a>

  25.       </span></dt><dd><p>

  26.         Enables or disables the query planner's use of gather

  27.         merge plan types. The default is <code class="literal">on</code>.

  28.        </p></dd><dt id="GUC-ENABLE-HASHAGG"><span class="term"><code class="varname">enable_hashagg</code> (<code class="type">boolean</code>)

  29.       <a id="id-1.6.6.10.2.3.3.1.3" class="indexterm"></a>

  30.       </span></dt><dd><p>

  31.         Enables or disables the query planner's use of hashed

  32.         aggregation plan types. The default is <code class="literal">on</code>.

  33.        </p></dd><dt id="GUC-ENABLE-HASHJOIN"><span class="term"><code class="varname">enable_hashjoin</code> (<code class="type">boolean</code>)

  34.       <a id="id-1.6.6.10.2.3.4.1.3" class="indexterm"></a>

  35.       </span></dt><dd><p>

  36.         Enables or disables the query planner's use of hash-join plan

  37.         types. The default is <code class="literal">on</code>.

  38.        </p></dd><dt id="GUC-ENABLE-INDEXSCAN"><span class="term"><code class="varname">enable_indexscan</code> (<code class="type">boolean</code>)

  39.       <a id="id-1.6.6.10.2.3.5.1.3" class="indexterm"></a>

  40.       <a id="id-1.6.6.10.2.3.5.1.4" class="indexterm"></a>

  41.       </span></dt><dd><p>

  42.         Enables or disables the query planner's use of index-scan plan

  43.         types. The default is <code class="literal">on</code>.

  44.        </p></dd><dt id="GUC-ENABLE-INDEXONLYSCAN"><span class="term"><code class="varname">enable_indexonlyscan</code> (<code class="type">boolean</code>)

  45.       <a id="id-1.6.6.10.2.3.6.1.3" class="indexterm"></a>

  46.       </span></dt><dd><p>

  47.         Enables or disables the query planner's use of index-only-scan plan

  48.         types (see <a class="xref" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes">Section 11.9</a>).

  49.         The default is <code class="literal">on</code>.

  50.        </p></dd><dt id="GUC-ENABLE-MATERIAL"><span class="term"><code class="varname">enable_material</code> (<code class="type">boolean</code>)

  51.       <a id="id-1.6.6.10.2.3.7.1.3" class="indexterm"></a>

  52.       </span></dt><dd><p>

  53.         Enables or disables the query planner's use of materialization.

  54.         It is impossible to suppress materialization entirely,

  55.         but turning this variable off prevents the planner from inserting

  56.         materialize nodes except in cases where it is required for correctness.

  57.         The default is <code class="literal">on</code>.

  58.        </p></dd><dt id="GUC-ENABLE-MERGEJOIN"><span class="term"><code class="varname">enable_mergejoin</code> (<code class="type">boolean</code>)

  59.       <a id="id-1.6.6.10.2.3.8.1.3" class="indexterm"></a>

  60.       </span></dt><dd><p>

  61.         Enables or disables the query planner's use of merge-join plan

  62.         types. The default is <code class="literal">on</code>.

  63.        </p></dd><dt id="GUC-ENABLE-NESTLOOP"><span class="term"><code class="varname">enable_nestloop</code> (<code class="type">boolean</code>)

  64.       <a id="id-1.6.6.10.2.3.9.1.3" class="indexterm"></a>

  65.       </span></dt><dd><p>

  66.         Enables or disables the query planner's use of nested-loop join

  67.         plans. It is impossible to suppress nested-loop joins entirely,

  68.         but turning this variable off discourages the planner from using

  69.         one if there are other methods available. The default is

  70.         <code class="literal">on</code>.

  71.        </p></dd><dt id="GUC-ENABLE-PARALLEL-APPEND"><span class="term"><code class="varname">enable_parallel_append</code> (<code class="type">boolean</code>)

  72.       <a id="id-1.6.6.10.2.3.10.1.3" class="indexterm"></a>

  73.       </span></dt><dd><p>

  74.         Enables or disables the query planner's use of parallel-aware

  75.         append plan types. The default is <code class="literal">on</code>.

  76.        </p></dd><dt id="GUC-ENABLE-PARALLEL-HASH"><span class="term"><code class="varname">enable_parallel_hash</code> (<code class="type">boolean</code>)

  77.        <a id="id-1.6.6.10.2.3.11.1.3" class="indexterm"></a>

  78.       </span></dt><dd><p>

  79.         Enables or disables the query planner's use of hash-join plan

  80.         types with parallel hash. Has no effect if hash-join plans are not

  81.         also enabled. The default is <code class="literal">on</code>.

  82.        </p></dd><dt id="GUC-ENABLE-PARTITION-PRUNING"><span class="term"><code class="varname">enable_partition_pruning</code> (<code class="type">boolean</code>)

  83.        <a id="id-1.6.6.10.2.3.12.1.3" class="indexterm"></a>

  84.       </span></dt><dd><p>

  85.         Enables or disables the query planner's ability to eliminate a

  86.         partitioned table's partitions from query plans.  This also controls

  87.         the planner's ability to generate query plans which allow the query

  88.         executor to remove (ignore) partitions during query execution.  The

  89.         default is <code class="literal">on</code>.

  90.         See <a class="xref" href="ddl-partitioning.html#DDL-PARTITION-PRUNING" title="5.11.4. Partition Pruning">Section 5.11.4</a> for details.

  91.        </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-JOIN"><span class="term"><code class="varname">enable_partitionwise_join</code> (<code class="type">boolean</code>)

  92.       <a id="id-1.6.6.10.2.3.13.1.3" class="indexterm"></a>

  93.       </span></dt><dd><p>

  94.         Enables or disables the query planner's use of partitionwise join,

  95.         which allows a join between partitioned tables to be performed by

  96.         joining the matching partitions.  Partitionwise join currently applies

  97.         only when the join conditions include all the partition keys, which

  98.         must be of the same data type and have exactly matching sets of child

  99.         partitions.  Because partitionwise join planning can use significantly

  100.         more CPU time and memory during planning, the default is

  101.         <code class="literal">off</code>.

  102.        </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-AGGREGATE"><span class="term"><code class="varname">enable_partitionwise_aggregate</code> (<code class="type">boolean</code>)

  103.       <a id="id-1.6.6.10.2.3.14.1.3" class="indexterm"></a>

  104.       </span></dt><dd><p>

  105.         Enables or disables the query planner's use of partitionwise grouping

  106.         or aggregation, which allows grouping or aggregation on a partitioned

  107.         tables performed separately for each partition.  If the <code class="literal">GROUP

  108.         BY</code> clause does not include the partition keys, only partial

  109.         aggregation can be performed on a per-partition basis, and

  110.         finalization must be performed later.  Because partitionwise grouping

  111.         or aggregation can use significantly more CPU time and memory during

  112.         planning, the default is <code class="literal">off</code>.

  113.        </p></dd><dt id="GUC-ENABLE-SEQSCAN"><span class="term"><code class="varname">enable_seqscan</code> (<code class="type">boolean</code>)

  114.       <a id="id-1.6.6.10.2.3.15.1.3" class="indexterm"></a>

  115.       <a id="id-1.6.6.10.2.3.15.1.4" class="indexterm"></a>

  116.       </span></dt><dd><p>

  117.         Enables or disables the query planner's use of sequential scan

  118.         plan types. It is impossible to suppress sequential scans

  119.         entirely, but turning this variable off discourages the planner

  120.         from using one if there are other methods available. The

  121.         default is <code class="literal">on</code>.

  122.        </p></dd><dt id="GUC-ENABLE-SORT"><span class="term"><code class="varname">enable_sort</code> (<code class="type">boolean</code>)

  123.       <a id="id-1.6.6.10.2.3.16.1.3" class="indexterm"></a>

  124.       </span></dt><dd><p>

  125.         Enables or disables the query planner's use of explicit sort

  126.         steps. It is impossible to suppress explicit sorts entirely,

  127.         but turning this variable off discourages the planner from

  128.         using one if there are other methods available. The default

  129.         is <code class="literal">on</code>.

  130.        </p></dd><dt id="GUC-ENABLE-TIDSCAN"><span class="term"><code class="varname">enable_tidscan</code> (<code class="type">boolean</code>)

  131.       <a id="id-1.6.6.10.2.3.17.1.3" class="indexterm"></a>

  132.       </span></dt><dd><p>

  133.         Enables or disables the query planner's use of <acronym class="acronym">TID</acronym>

  134.         scan plan types. The default is <code class="literal">on</code>.

  135.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-CONSTANTS"><div class="titlepage"><div><div><h3 class="title">19.7.2. Planner Cost Constants</h3></div></div></div><p>

  136.      The <em class="firstterm">cost</em> variables described in this section are measured

  137.      on an arbitrary scale.  Only their relative values matter, hence

  138.      scaling them all up or down by the same factor will result in no change

  139.      in the planner's choices.  By default, these cost variables are based on

  140.      the cost of sequential page fetches; that is,

  141.      <code class="varname">seq_page_cost</code> is conventionally set to <code class="literal">1.0</code>

  142.      and the other cost variables are set with reference to that.  But

  143.      you can use a different scale if you prefer, such as actual execution

  144.      times in milliseconds on a particular machine.

  145.     </p><div class="note"><h3 class="title">Note</h3><p>

  146.      Unfortunately, there is no well-defined method for determining ideal

  147.      values for the cost variables.  They are best treated as averages over

  148.      the entire mix of queries that a particular installation will receive.  This

  149.      means that changing them on the basis of just a few experiments is very

  150.      risky.

  151.     </p></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-SEQ-PAGE-COST"><span class="term"><code class="varname">seq_page_cost</code> (<code class="type">floating point</code>)

  152.       <a id="id-1.6.6.10.3.4.1.1.3" class="indexterm"></a>

  153.       </span></dt><dd><p>

  154.         Sets the planner's estimate of the cost of a disk page fetch

  155.         that is part of a series of sequential fetches.  The default is 1.0.

  156.         This value can be overridden for tables and indexes in a particular

  157.         tablespace by setting the tablespace parameter of the same name

  158.         (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>).

  159.        </p></dd><dt id="GUC-RANDOM-PAGE-COST"><span class="term"><code class="varname">random_page_cost</code> (<code class="type">floating point</code>)

  160.       <a id="id-1.6.6.10.3.4.2.1.3" class="indexterm"></a>

  161.       </span></dt><dd><p>

  162.         Sets the planner's estimate of the cost of a

  163.         non-sequentially-fetched disk page.  The default is 4.0.

  164.         This value can be overridden for tables and indexes in a particular

  165.         tablespace by setting the tablespace parameter of the same name

  166.         (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>).

  167.        </p><p>

  168.         Reducing this value relative to <code class="varname">seq_page_cost</code>

  169.         will cause the system to prefer index scans; raising it will

  170.         make index scans look relatively more expensive.  You can raise

  171.         or lower both values together to change the importance of disk I/O

  172.         costs relative to CPU costs, which are described by the following

  173.         parameters.

  174.        </p><p>

  175.         Random access to mechanical disk storage is normally much more expensive

  176.         than four times sequential access.  However, a lower default is used

  177.         (4.0) because the majority of random accesses to disk, such as indexed

  178.         reads, are assumed to be in cache.  The default value can be thought of

  179.         as modeling random access as 40 times slower than sequential, while

  180.         expecting 90% of random reads to be cached.

  181.        </p><p>

  182.         If you believe a 90% cache rate is an incorrect assumption

  183.         for your workload, you can increase random_page_cost to better

  184.         reflect the true cost of random storage reads. Correspondingly,

  185.         if your data is likely to be completely in cache, such as when

  186.         the database is smaller than the total server memory, decreasing

  187.         random_page_cost can be appropriate.  Storage that has a low random

  188.         read cost relative to sequential, e.g. solid-state drives, might

  189.         also be better modeled with a lower value for random_page_cost,

  190.         e.g., <code class="literal">1.1</code>.

  191.        </p><div class="tip"><h3 class="title">Tip</h3><p>

  192.          Although the system will let you set <code class="varname">random_page_cost</code> to

  193.          less than <code class="varname">seq_page_cost</code>, it is not physically sensible

  194.          to do so.  However, setting them equal makes sense if the database

  195.          is entirely cached in RAM, since in that case there is no penalty

  196.          for touching pages out of sequence.  Also, in a heavily-cached

  197.          database you should lower both values relative to the CPU parameters,

  198.          since the cost of fetching a page already in RAM is much smaller

  199.          than it would normally be.

  200.         </p></div></dd><dt id="GUC-CPU-TUPLE-COST"><span class="term"><code class="varname">cpu_tuple_cost</code> (<code class="type">floating point</code>)

  201.       <a id="id-1.6.6.10.3.4.3.1.3" class="indexterm"></a>

  202.       </span></dt><dd><p>

  203.         Sets the planner's estimate of the cost of processing

  204.         each row during a query.

  205.         The default is 0.01.

  206.        </p></dd><dt id="GUC-CPU-INDEX-TUPLE-COST"><span class="term"><code class="varname">cpu_index_tuple_cost</code> (<code class="type">floating point</code>)

  207.       <a id="id-1.6.6.10.3.4.4.1.3" class="indexterm"></a>

  208.       </span></dt><dd><p>

  209.         Sets the planner's estimate of the cost of processing

  210.         each index entry during an index scan.

  211.         The default is 0.005.

  212.        </p></dd><dt id="GUC-CPU-OPERATOR-COST"><span class="term"><code class="varname">cpu_operator_cost</code> (<code class="type">floating point</code>)

  213.       <a id="id-1.6.6.10.3.4.5.1.3" class="indexterm"></a>

  214.       </span></dt><dd><p>

  215.         Sets the planner's estimate of the cost of processing each

  216.         operator or function executed during a query.

  217.         The default is 0.0025.

  218.        </p></dd><dt id="GUC-PARALLEL-SETUP-COST"><span class="term"><code class="varname">parallel_setup_cost</code> (<code class="type">floating point</code>)

  219.       <a id="id-1.6.6.10.3.4.6.1.3" class="indexterm"></a>

  220.       </span></dt><dd><p>

  221.         Sets the planner's estimate of the cost of launching parallel worker

  222.         processes.

  223.         The default is 1000.

  224.        </p></dd><dt id="GUC-PARALLEL-TUPLE-COST"><span class="term"><code class="varname">parallel_tuple_cost</code> (<code class="type">floating point</code>)

  225.       <a id="id-1.6.6.10.3.4.7.1.3" class="indexterm"></a>

  226.       </span></dt><dd><p>

  227.         Sets the planner's estimate of the cost of transferring one tuple

  228.         from a parallel worker process to another process.

  229.         The default is 0.1.

  230.        </p></dd><dt id="GUC-MIN-PARALLEL-TABLE-SCAN-SIZE"><span class="term"><code class="varname">min_parallel_table_scan_size</code> (<code class="type">integer</code>)

  231.       <a id="id-1.6.6.10.3.4.8.1.3" class="indexterm"></a>

  232.       </span></dt><dd><p>

  233.         Sets the minimum amount of table data that must be scanned in order

  234.         for a parallel scan to be considered.  For a parallel sequential scan,

  235.         the amount of table data scanned is always equal to the size of the

  236.         table, but when indexes are used the amount of table data

  237.         scanned will normally be less.

  238.         If this value is specified without units, it is taken as blocks,

  239.         that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.

  240.         The default is 8 megabytes (<code class="literal">8MB</code>).

  241.        </p></dd><dt id="GUC-MIN-PARALLEL-INDEX-SCAN-SIZE"><span class="term"><code class="varname">min_parallel_index_scan_size</code> (<code class="type">integer</code>)

  242.       <a id="id-1.6.6.10.3.4.9.1.3" class="indexterm"></a>

  243.       </span></dt><dd><p>

  244.         Sets the minimum amount of index data that must be scanned in order

  245.         for a parallel scan to be considered.  Note that a parallel index scan

  246.         typically won't touch the entire index; it is the number of pages

  247.         which the planner believes will actually be touched by the scan which

  248.         is relevant.

  249.         If this value is specified without units, it is taken as blocks,

  250.         that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.

  251.         The default is 512 kilobytes (<code class="literal">512kB</code>).

  252.        </p></dd><dt id="GUC-EFFECTIVE-CACHE-SIZE"><span class="term"><code class="varname">effective_cache_size</code> (<code class="type">integer</code>)

  253.       <a id="id-1.6.6.10.3.4.10.1.3" class="indexterm"></a>

  254.       </span></dt><dd><p>

  255.         Sets the planner's assumption about the effective size of the

  256.         disk cache that is available to a single query.  This is

  257.         factored into estimates of the cost of using an index; a

  258.         higher value makes it more likely index scans will be used, a

  259.         lower value makes it more likely sequential scans will be

  260.         used. When setting this parameter you should consider both

  261.         <span class="productname">PostgreSQL</span>'s shared buffers and the

  262.         portion of the kernel's disk cache that will be used for

  263.         <span class="productname">PostgreSQL</span> data files, though some

  264.         data might exist in both places. Also, take

  265.         into account the expected number of concurrent queries on different

  266.         tables, since they will have to share the available

  267.         space.  This parameter has no effect on the size of shared

  268.         memory allocated by <span class="productname">PostgreSQL</span>, nor

  269.         does it reserve kernel disk cache; it is used only for estimation

  270.         purposes.  The system also does not assume data remains in

  271.         the disk cache between queries.

  272.         If this value is specified without units, it is taken as blocks,

  273.         that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.

  274.         The default is 4 gigabytes (<code class="literal">4GB</code>).

  275.         (If <code class="symbol">BLCKSZ</code> is not 8kB, the default value scales

  276.         proportionally to it.)

  277.        </p></dd><dt id="GUC-JIT-ABOVE-COST"><span class="term"><code class="varname">jit_above_cost</code> (<code class="type">floating point</code>)

  278.       <a id="id-1.6.6.10.3.4.11.1.3" class="indexterm"></a>

  279.       </span></dt><dd><p>

  280.         Sets the query cost above which JIT compilation is activated, if

  281.         enabled (see <a class="xref" href="jit.html" title="Chapter 31. Just-in-Time Compilation (JIT)">Chapter 31</a>).

  282.         Performing <acronym class="acronym">JIT</acronym> costs planning time but can

  283.         accelerate query execution.

  284.         Setting this to <code class="literal">-1</code> disables JIT compilation.

  285.         The default is <code class="literal">100000</code>.

  286.        </p></dd><dt id="GUC-JIT-INLINE-ABOVE-COST"><span class="term"><code class="varname">jit_inline_above_cost</code> (<code class="type">floating point</code>)

  287.       <a id="id-1.6.6.10.3.4.12.1.3" class="indexterm"></a>

  288.       </span></dt><dd><p>

  289.         Sets the query cost above which JIT compilation attempts to inline

  290.         functions and operators.  Inlining adds planning time, but can

  291.         improve execution speed.  It is not meaningful to set this to less

  292.         than <code class="varname">jit_above_cost</code>.

  293.         Setting this to <code class="literal">-1</code> disables inlining.

  294.         The default is <code class="literal">500000</code>.

  295.        </p></dd><dt id="GUC-JIT-OPTIMIZE-ABOVE-COST"><span class="term"><code class="varname">jit_optimize_above_cost</code> (<code class="type">floating point</code>)

  296.       <a id="id-1.6.6.10.3.4.13.1.3" class="indexterm"></a>

  297.       </span></dt><dd><p>

  298.         Sets the query cost above which JIT compilation applies expensive

  299.         optimizations.  Such optimization adds planning time, but can improve

  300.         execution speed.  It is not meaningful to set this to less

  301.         than <code class="varname">jit_above_cost</code>, and it is unlikely to be

  302.         beneficial to set it to more

  303.         than <code class="varname">jit_inline_above_cost</code>.

  304.         Setting this to <code class="literal">-1</code> disables expensive optimizations.

  305.         The default is <code class="literal">500000</code>.

  306.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-GEQO"><div class="titlepage"><div><div><h3 class="title">19.7.3. Genetic Query Optimizer</h3></div></div></div><p>

  307.       The genetic query optimizer (GEQO) is an algorithm that does query

  308.       planning using heuristic searching.  This reduces planning time for

  309.       complex queries (those joining many relations), at the cost of producing

  310.       plans that are sometimes inferior to those found by the normal

  311.       exhaustive-search algorithm.

  312.       For more information see <a class="xref" href="geqo.html" title="Chapter 59. Genetic Query Optimizer">Chapter 59</a>.

  313.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-GEQO"><span class="term"><code class="varname">geqo</code> (<code class="type">boolean</code>)

  314.       <a id="id-1.6.6.10.4.3.1.1.3" class="indexterm"></a>

  315.       <a id="id-1.6.6.10.4.3.1.1.4" class="indexterm"></a>

  316.       <a id="id-1.6.6.10.4.3.1.1.5" class="indexterm"></a>

  317.       </span></dt><dd><p>

  318.         Enables or disables genetic query optimization.

  319.         This is on by default.  It is usually best not to turn it off in

  320.         production; the <code class="varname">geqo_threshold</code> variable provides

  321.         more granular control of GEQO.

  322.        </p></dd><dt id="GUC-GEQO-THRESHOLD"><span class="term"><code class="varname">geqo_threshold</code> (<code class="type">integer</code>)

  323.       <a id="id-1.6.6.10.4.3.2.1.3" class="indexterm"></a>

  324.       </span></dt><dd><p>

  325.         Use genetic query optimization to plan queries with at least

  326.         this many <code class="literal">FROM</code> items involved. (Note that a

  327.         <code class="literal">FULL OUTER JOIN</code> construct counts as only one <code class="literal">FROM</code>

  328.         item.) The default is 12. For simpler queries it is usually best

  329.         to use the regular, exhaustive-search planner, but for queries with

  330.         many tables the exhaustive search takes too long, often

  331.         longer than the penalty of executing a suboptimal plan.  Thus,

  332.         a threshold on the size of the query is a convenient way to manage

  333.         use of GEQO.

  334.        </p></dd><dt id="GUC-GEQO-EFFORT"><span class="term"><code class="varname">geqo_effort</code> (<code class="type">integer</code>)

  335.       <a id="id-1.6.6.10.4.3.3.1.3" class="indexterm"></a>

  336.       </span></dt><dd><p>

  337.         Controls the trade-off between planning time and query plan

  338.         quality in GEQO. This variable must be an integer in the

  339.         range from 1 to 10. The default value is five. Larger values

  340.         increase the time spent doing query planning, but also

  341.         increase the likelihood that an efficient query plan will be

  342.         chosen.

  343.        </p><p>

  344.         <code class="varname">geqo_effort</code> doesn't actually do anything

  345.         directly; it is only used to compute the default values for

  346.         the other variables that influence GEQO behavior (described

  347.         below). If you prefer, you can set the other parameters by

  348.         hand instead.

  349.        </p></dd><dt id="GUC-GEQO-POOL-SIZE"><span class="term"><code class="varname">geqo_pool_size</code> (<code class="type">integer</code>)

  350.       <a id="id-1.6.6.10.4.3.4.1.3" class="indexterm"></a>

  351.       </span></dt><dd><p>

  352.         Controls the pool size used by GEQO, that is the

  353.         number of individuals in the genetic population.  It must be

  354.         at least two, and useful values are typically 100 to 1000.  If

  355.         it is set to zero (the default setting) then a suitable

  356.         value is chosen based on <code class="varname">geqo_effort</code> and

  357.         the number of tables in the query.

  358.        </p></dd><dt id="GUC-GEQO-GENERATIONS"><span class="term"><code class="varname">geqo_generations</code> (<code class="type">integer</code>)

  359.       <a id="id-1.6.6.10.4.3.5.1.3" class="indexterm"></a>

  360.       </span></dt><dd><p>

  361.         Controls the number of generations used by GEQO, that is

  362.         the number of iterations of the algorithm.  It must

  363.         be at least one, and useful values are in the same range as

  364.         the pool size.  If it is set to zero (the default setting)

  365.         then a suitable value is chosen based on

  366.         <code class="varname">geqo_pool_size</code>.

  367.        </p></dd><dt id="GUC-GEQO-SELECTION-BIAS"><span class="term"><code class="varname">geqo_selection_bias</code> (<code class="type">floating point</code>)

  368.       <a id="id-1.6.6.10.4.3.6.1.3" class="indexterm"></a>

  369.       </span></dt><dd><p>

  370.         Controls the selection bias used by GEQO. The selection bias

  371.         is the selective pressure within the population. Values can be

  372.         from 1.50 to 2.00; the latter is the default.

  373.        </p></dd><dt id="GUC-GEQO-SEED"><span class="term"><code class="varname">geqo_seed</code> (<code class="type">floating point</code>)

  374.       <a id="id-1.6.6.10.4.3.7.1.3" class="indexterm"></a>

  375.       </span></dt><dd><p>

  376.         Controls the initial value of the random number generator used

  377.         by GEQO to select random paths through the join order search space.

  378.         The value can range from zero (the default) to one.  Varying the

  379.         value changes the set of join paths explored, and may result in a

  380.         better or worse best path being found.

  381.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-OTHER"><div class="titlepage"><div><div><h3 class="title">19.7.4. Other Planner Options</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-DEFAULT-STATISTICS-TARGET"><span class="term"><code class="varname">default_statistics_target</code> (<code class="type">integer</code>)

  382.       <a id="id-1.6.6.10.5.2.1.1.3" class="indexterm"></a>

  383.       </span></dt><dd><p>

  384.         Sets the default statistics target for table columns without

  385.         a column-specific target set via <code class="command">ALTER TABLE

  386.         SET STATISTICS</code>.  Larger values increase the time needed to

  387.         do <code class="command">ANALYZE</code>, but might improve the quality of the

  388.         planner's estimates. The default is 100. For more information

  389.         on the use of statistics by the <span class="productname">PostgreSQL</span>

  390.         query planner, refer to <a class="xref" href="planner-stats.html" title="14.2. Statistics Used by the Planner">Section 14.2</a>.

  391.        </p></dd><dt id="GUC-CONSTRAINT-EXCLUSION"><span class="term"><code class="varname">constraint_exclusion</code> (<code class="type">enum</code>)

  392.       <a id="id-1.6.6.10.5.2.2.1.3" class="indexterm"></a>

  393.       <a id="id-1.6.6.10.5.2.2.1.4" class="indexterm"></a>

  394.       </span></dt><dd><p>

  395.         Controls the query planner's use of table constraints to

  396.         optimize queries.

  397.         The allowed values of <code class="varname">constraint_exclusion</code> are

  398.         <code class="literal">on</code> (examine constraints for all tables),

  399.         <code class="literal">off</code> (never examine constraints), and

  400.         <code class="literal">partition</code> (examine constraints only for inheritance

  401.         child tables and <code class="literal">UNION ALL</code> subqueries).

  402.         <code class="literal">partition</code> is the default setting.

  403.         It is often used with traditional inheritance trees to improve

  404.         performance.

  405.       </p><p>

  406.         When this parameter allows it for a particular table, the planner

  407.         compares query conditions with the table's <code class="literal">CHECK</code>

  408.         constraints, and omits scanning tables for which the conditions

  409.         contradict the constraints.  For example:

  410. 

  411. </p><pre class="programlisting">

  412. CREATE TABLE parent(key integer, ...);

  413. CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);

  414. CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);

  415. ...

  416. SELECT * FROM parent WHERE key = 2400;

  417. </pre><p>

  418. 

  419.         With constraint exclusion enabled, this <code class="command">SELECT</code>

  420.         will not scan <code class="structname">child1000</code> at all, improving performance.

  421.        </p><p>

  422.         Currently, constraint exclusion is enabled by default

  423.         only for cases that are often used to implement table partitioning via

  424.         inheritance trees.  Turning it on for all tables imposes extra

  425.         planning overhead that is quite noticeable on simple queries, and most

  426.         often will yield no benefit for simple queries.  If you have no

  427.         tables that are partitioned using traditional inheritance, you might

  428.         prefer to turn it off entirely.  (Note that the equivalent feature for

  429.         partitioned tables is controlled by a separate parameter,

  430.         <a class="xref" href="runtime-config-query.html#GUC-ENABLE-PARTITION-PRUNING">enable_partition_pruning</a>.)

  431.        </p><p>

  432.         Refer to <a class="xref" href="ddl-partitioning.html#DDL-PARTITIONING-CONSTRAINT-EXCLUSION" title="5.11.5. Partitioning and Constraint Exclusion">Section 5.11.5</a> for

  433.         more information on using constraint exclusion to implement

  434.         partitioning.

  435.        </p></dd><dt id="GUC-CURSOR-TUPLE-FRACTION"><span class="term"><code class="varname">cursor_tuple_fraction</code> (<code class="type">floating point</code>)

  436.       <a id="id-1.6.6.10.5.2.3.1.3" class="indexterm"></a>

  437.       </span></dt><dd><p>

  438.         Sets the planner's estimate of the fraction of a cursor's rows that

  439.         will be retrieved.  The default is 0.1.  Smaller values of this

  440.         setting bias the planner towards using <span class="quote">“<span class="quote">fast start</span>”</span> plans

  441.         for cursors, which will retrieve the first few rows quickly while

  442.         perhaps taking a long time to fetch all rows.  Larger values

  443.         put more emphasis on the total estimated time.  At the maximum

  444.         setting of 1.0, cursors are planned exactly like regular queries,

  445.         considering only the total estimated time and not how soon the

  446.         first rows might be delivered.

  447.        </p></dd><dt id="GUC-FROM-COLLAPSE-LIMIT"><span class="term"><code class="varname">from_collapse_limit</code> (<code class="type">integer</code>)

  448.       <a id="id-1.6.6.10.5.2.4.1.3" class="indexterm"></a>

  449.       </span></dt><dd><p>

  450.         The planner will merge sub-queries into upper queries if the

  451.         resulting <code class="literal">FROM</code> list would have no more than

  452.         this many items.  Smaller values reduce planning time but might

  453.         yield inferior query plans.  The default is eight.

  454.         For more information see <a class="xref" href="explicit-joins.html" title="14.3. Controlling the Planner with Explicit JOIN Clauses">Section 14.3</a>.

  455.        </p><p>

  456.         Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more

  457.         may trigger use of the GEQO planner, resulting in non-optimal

  458.         plans.  See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="19.7.3. Genetic Query Optimizer">Section 19.7.3</a>.

  459.        </p></dd><dt id="GUC-JIT"><span class="term"><code class="varname">jit</code> (<code class="type">boolean</code>)

  460.       <a id="id-1.6.6.10.5.2.5.1.3" class="indexterm"></a>

  461.       </span></dt><dd><p>

  462.         Determines whether <acronym class="acronym">JIT</acronym> compilation may be used by

  463.         <span class="productname">PostgreSQL</span>, if available (see <a class="xref" href="jit.html" title="Chapter 31. Just-in-Time Compilation (JIT)">Chapter 31</a>).

  464.         The default is <code class="literal">on</code>.

  465.        </p></dd><dt id="GUC-JOIN-COLLAPSE-LIMIT"><span class="term"><code class="varname">join_collapse_limit</code> (<code class="type">integer</code>)

  466.       <a id="id-1.6.6.10.5.2.6.1.3" class="indexterm"></a>

  467.       </span></dt><dd><p>

  468.         The planner will rewrite explicit <code class="literal">JOIN</code>

  469.         constructs (except <code class="literal">FULL JOIN</code>s) into lists of

  470.         <code class="literal">FROM</code> items whenever a list of no more than this many items

  471.         would result.  Smaller values reduce planning time but might

  472.         yield inferior query plans.

  473.        </p><p>

  474.         By default, this variable is set the same as

  475.         <code class="varname">from_collapse_limit</code>, which is appropriate

  476.         for most uses. Setting it to 1 prevents any reordering of

  477.         explicit <code class="literal">JOIN</code>s. Thus, the explicit join order

  478.         specified in the query will be the actual order in which the

  479.         relations are joined. Because the query planner does not always choose

  480.         the optimal join order, advanced users can elect to

  481.         temporarily set this variable to 1, and then specify the join

  482.         order they desire explicitly.

  483.         For more information see <a class="xref" href="explicit-joins.html" title="14.3. Controlling the Planner with Explicit JOIN Clauses">Section 14.3</a>.

  484.        </p><p>

  485.         Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more

  486.         may trigger use of the GEQO planner, resulting in non-optimal

  487.         plans.  See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="19.7.3. Genetic Query Optimizer">Section 19.7.3</a>.

  488.        </p></dd><dt id="GUC-PARALLEL-LEADER-PARTICIPATION"><span class="term">

  489.        <code class="varname">parallel_leader_participation</code> (<code class="type">boolean</code>)

  490.        <a id="id-1.6.6.10.5.2.7.1.3" class="indexterm"></a>

  491.       </span></dt><dd><p>

  492.         Allows the leader process to execute the query plan under

  493.         <code class="literal">Gather</code> and <code class="literal">Gather Merge</code> nodes

  494.         instead of waiting for worker processes.  The default is

  495.         <code class="literal">on</code>.  Setting this value to <code class="literal">off</code>

  496.         reduces the likelihood that workers will become blocked because the

  497.         leader is not reading tuples fast enough, but requires the leader

  498.         process to wait for worker processes to start up before the first

  499.         tuples can be produced.  The degree to which the leader can help or

  500.         hinder performance depends on the plan type, number of workers and

  501.         query duration.

  502.        </p></dd><dt id="GUC-FORCE-PARALLEL-MODE"><span class="term"><code class="varname">force_parallel_mode</code> (<code class="type">enum</code>)

  503.       <a id="id-1.6.6.10.5.2.8.1.3" class="indexterm"></a>

  504.       </span></dt><dd><p>

  505.         Allows the use of parallel queries for testing purposes even in cases

  506.         where no performance benefit is expected.

  507.         The allowed values of <code class="varname">force_parallel_mode</code> are

  508.         <code class="literal">off</code> (use parallel mode only when it is expected to improve

  509.         performance), <code class="literal">on</code> (force parallel query for all queries

  510.         for which it is thought to be safe), and <code class="literal">regress</code> (like

  511.         <code class="literal">on</code>, but with additional behavior changes as explained

  512.         below).

  513.        </p><p>

  514.         More specifically, setting this value to <code class="literal">on</code> will add

  515.         a <code class="literal">Gather</code> node to the top of any query plan for which this

  516.         appears to be safe, so that the query runs inside of a parallel worker.

  517.         Even when a parallel worker is not available or cannot be used,

  518.         operations such as starting a subtransaction that would be prohibited

  519.         in a parallel query context will be prohibited unless the planner

  520.         believes that this will cause the query to fail.  If failures or

  521.         unexpected results occur when this option is set, some functions used

  522.         by the query may need to be marked <code class="literal">PARALLEL UNSAFE</code>

  523.         (or, possibly, <code class="literal">PARALLEL RESTRICTED</code>).

  524.        </p><p>

  525.         Setting this value to <code class="literal">regress</code> has all of the same effects

  526.         as setting it to <code class="literal">on</code> plus some additional effects that are

  527.         intended to facilitate automated regression testing.  Normally,

  528.         messages from a parallel worker include a context line indicating that,

  529.         but a setting of <code class="literal">regress</code> suppresses this line so that the

  530.         output is the same as in non-parallel execution.  Also,

  531.         the <code class="literal">Gather</code> nodes added to plans by this setting are hidden

  532.         in <code class="literal">EXPLAIN</code> output so that the output matches what

  533.         would be obtained if this setting were turned <code class="literal">off</code>.

  534.        </p></dd><dt id="GUC-PLAN-CACHE_MODE"><span class="term"><code class="varname">plan_cache_mode</code> (<code class="type">enum</code>)

  535.       <a id="id-1.6.6.10.5.2.9.1.3" class="indexterm"></a>

  536.       </span></dt><dd><p>

  537.         Prepared statements (either explicitly prepared or implicitly

  538.         generated, for example by PL/pgSQL) can be executed using custom or

  539.         generic plans.  Custom plans are made afresh for each execution

  540.         using its specific set of parameter values, while generic plans do

  541.         not rely on the parameter values and can be re-used across

  542.         executions.  Thus, use of a generic plan saves planning time, but if

  543.         the ideal plan depends strongly on the parameter values then a

  544.         generic plan may be inefficient.  The choice between these options

  545.         is normally made automatically, but it can be overridden

  546.         with <code class="varname">plan_cache_mode</code>.

  547.         The allowed values are <code class="literal">auto</code> (the default),

  548.         <code class="literal">force_custom_plan</code> and

  549.         <code class="literal">force_generic_plan</code>.

  550.         This setting is considered when a cached plan is to be executed,

  551.         not when it is prepared.

  552.         For more information see <a class="xref" href="sql-prepare.html" title="PREPARE"><span class="refentrytitle">PREPARE</span></a>.

  553.        </p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-replication.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-logging.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">19.6. Replication </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 19.8. Error Reporting and Logging</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1