Team Ai
Datasetpublic

codekingpro/portable-devtools

sourceHugging Faceupdated 5mo agoView on Hugging Face
1likes15kdownloads
runtime-config-query.html558 linesDownload Raw Back to html
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>20.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 Vsnapshot" /><link rel="prev" href="runtime-config-replication.html" title="20.6. Replication" /><link rel="next" href="runtime-config-logging.html" title="20.8. Error Reporting and Logging" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">20.7. Query Planning</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-replication.html" title="20.6. Replication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 20. Server Configuration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="runtime-config-logging.html" title="20.8. Error Reporting and Logging">Next</a></td></tr></table><hr /></div><div class="sect1" id="RUNTIME-CONFIG-QUERY"><div class="titlepage"><div><div><h2 class="title" style="clear: both">20.7. Query Planning <a href="#RUNTIME-CONFIG-QUERY" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-ENABLE">20.7.1. Planner Method Configuration</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS">20.7.2. Planner Cost Constants</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO">20.7.3. Genetic Query Optimizer</a></span></dt><dt><span class="sect2"><a href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER">20.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">20.7.1. Planner Method Configuration <a href="#RUNTIME-CONFIG-QUERY-ENABLE" class="id_link">#</a></h3></div></div></div><p>3       These configuration parameters provide a crude method of4       influencing the query plans chosen by the query optimizer. If5       the default plan chosen by the optimizer for a particular query6       is not optimal, a <span class="emphasis"><em>temporary</em></span> solution is to use one7       of these configuration parameters to force the optimizer to8       choose a different plan.9       Better ways to improve the quality of the10       plans chosen by the optimizer include adjusting the planner cost11       constants (see <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS" title="20.7.2. Planner Cost Constants">Section 20.7.2</a>),12       running <a class="link" href="sql-analyze.html" title="ANALYZE"><code class="command">ANALYZE</code></a> manually, increasing13       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 for15       specific columns using <code class="command">ALTER TABLE SET16       STATISTICS</code>.17      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-ENABLE-ASYNC-APPEND"><span class="term"><code class="varname">enable_async_append</code> (<code class="type">boolean</code>)18      <a id="id-1.6.7.10.2.3.1.1.3" class="indexterm"></a>19      </span> <a href="#GUC-ENABLE-ASYNC-APPEND" class="id_link">#</a></dt><dd><p>20        Enables or disables the query planner's use of async-aware21        append plan types. The default is <code class="literal">on</code>.22       </p></dd><dt id="GUC-ENABLE-BITMAPSCAN"><span class="term"><code class="varname">enable_bitmapscan</code> (<code class="type">boolean</code>)23      <a id="id-1.6.7.10.2.3.2.1.3" class="indexterm"></a>24      <a id="id-1.6.7.10.2.3.2.1.4" class="indexterm"></a>25      </span> <a href="#GUC-ENABLE-BITMAPSCAN" class="id_link">#</a></dt><dd><p>26        Enables or disables the query planner's use of bitmap-scan plan27        types. The default is <code class="literal">on</code>.28       </p></dd><dt id="GUC-ENABLE-GATHERMERGE"><span class="term"><code class="varname">enable_gathermerge</code> (<code class="type">boolean</code>)29      <a id="id-1.6.7.10.2.3.3.1.3" class="indexterm"></a>30      </span> <a href="#GUC-ENABLE-GATHERMERGE" class="id_link">#</a></dt><dd><p>31        Enables or disables the query planner's use of gather32        merge plan types. The default is <code class="literal">on</code>.33       </p></dd><dt id="GUC-ENABLE-HASHAGG"><span class="term"><code class="varname">enable_hashagg</code> (<code class="type">boolean</code>)34      <a id="id-1.6.7.10.2.3.4.1.3" class="indexterm"></a>35      </span> <a href="#GUC-ENABLE-HASHAGG" class="id_link">#</a></dt><dd><p>36        Enables or disables the query planner's use of hashed37        aggregation plan types. The default is <code class="literal">on</code>.38       </p></dd><dt id="GUC-ENABLE-HASHJOIN"><span class="term"><code class="varname">enable_hashjoin</code> (<code class="type">boolean</code>)39      <a id="id-1.6.7.10.2.3.5.1.3" class="indexterm"></a>40      </span> <a href="#GUC-ENABLE-HASHJOIN" class="id_link">#</a></dt><dd><p>41        Enables or disables the query planner's use of hash-join plan42        types. The default is <code class="literal">on</code>.43       </p></dd><dt id="GUC-ENABLE-INCREMENTAL-SORT"><span class="term"><code class="varname">enable_incremental_sort</code> (<code class="type">boolean</code>)44      <a id="id-1.6.7.10.2.3.6.1.3" class="indexterm"></a>45      </span> <a href="#GUC-ENABLE-INCREMENTAL-SORT" class="id_link">#</a></dt><dd><p>46        Enables or disables the query planner's use of incremental sort steps.47        The default is <code class="literal">on</code>.48       </p></dd><dt id="GUC-ENABLE-INDEXSCAN"><span class="term"><code class="varname">enable_indexscan</code> (<code class="type">boolean</code>)49      <a id="id-1.6.7.10.2.3.7.1.3" class="indexterm"></a>50      <a id="id-1.6.7.10.2.3.7.1.4" class="indexterm"></a>51      </span> <a href="#GUC-ENABLE-INDEXSCAN" class="id_link">#</a></dt><dd><p>52        Enables or disables the query planner's use of index-scan plan53        types. The default is <code class="literal">on</code>.54       </p></dd><dt id="GUC-ENABLE-INDEXONLYSCAN"><span class="term"><code class="varname">enable_indexonlyscan</code> (<code class="type">boolean</code>)55      <a id="id-1.6.7.10.2.3.8.1.3" class="indexterm"></a>56      </span> <a href="#GUC-ENABLE-INDEXONLYSCAN" class="id_link">#</a></dt><dd><p>57        Enables or disables the query planner's use of index-only-scan plan58        types (see <a class="xref" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes">Section 11.9</a>).59        The default is <code class="literal">on</code>.60       </p></dd><dt id="GUC-ENABLE-MATERIAL"><span class="term"><code class="varname">enable_material</code> (<code class="type">boolean</code>)61      <a id="id-1.6.7.10.2.3.9.1.3" class="indexterm"></a>62      </span> <a href="#GUC-ENABLE-MATERIAL" class="id_link">#</a></dt><dd><p>63        Enables or disables the query planner's use of materialization.64        It is impossible to suppress materialization entirely,65        but turning this variable off prevents the planner from inserting66        materialize nodes except in cases where it is required for correctness.67        The default is <code class="literal">on</code>.68       </p></dd><dt id="GUC-ENABLE-MEMOIZE"><span class="term"><code class="varname">enable_memoize</code> (<code class="type">boolean</code>)69      <a id="id-1.6.7.10.2.3.10.1.3" class="indexterm"></a>70      </span> <a href="#GUC-ENABLE-MEMOIZE" class="id_link">#</a></dt><dd><p>71        Enables or disables the query planner's use of memoize plans for72        caching results from parameterized scans inside nested-loop joins.73        This plan type allows scans to the underlying plans to be skipped when74        the results for the current parameters are already in the cache.  Less75        commonly looked up results may be evicted from the cache when more76        space is required for new entries. The default is77        <code class="literal">on</code>.78       </p></dd><dt id="GUC-ENABLE-MERGEJOIN"><span class="term"><code class="varname">enable_mergejoin</code> (<code class="type">boolean</code>)79      <a id="id-1.6.7.10.2.3.11.1.3" class="indexterm"></a>80      </span> <a href="#GUC-ENABLE-MERGEJOIN" class="id_link">#</a></dt><dd><p>81        Enables or disables the query planner's use of merge-join plan82        types. The default is <code class="literal">on</code>.83       </p></dd><dt id="GUC-ENABLE-NESTLOOP"><span class="term"><code class="varname">enable_nestloop</code> (<code class="type">boolean</code>)84      <a id="id-1.6.7.10.2.3.12.1.3" class="indexterm"></a>85      </span> <a href="#GUC-ENABLE-NESTLOOP" class="id_link">#</a></dt><dd><p>86        Enables or disables the query planner's use of nested-loop join87        plans. It is impossible to suppress nested-loop joins entirely,88        but turning this variable off discourages the planner from using89        one if there are other methods available. The default is90        <code class="literal">on</code>.91       </p></dd><dt id="GUC-ENABLE-PARALLEL-APPEND"><span class="term"><code class="varname">enable_parallel_append</code> (<code class="type">boolean</code>)92      <a id="id-1.6.7.10.2.3.13.1.3" class="indexterm"></a>93      </span> <a href="#GUC-ENABLE-PARALLEL-APPEND" class="id_link">#</a></dt><dd><p>94        Enables or disables the query planner's use of parallel-aware95        append plan types. The default is <code class="literal">on</code>.96       </p></dd><dt id="GUC-ENABLE-PARALLEL-HASH"><span class="term"><code class="varname">enable_parallel_hash</code> (<code class="type">boolean</code>)97       <a id="id-1.6.7.10.2.3.14.1.3" class="indexterm"></a>98      </span> <a href="#GUC-ENABLE-PARALLEL-HASH" class="id_link">#</a></dt><dd><p>99        Enables or disables the query planner's use of hash-join plan100        types with parallel hash. Has no effect if hash-join plans are not101        also enabled. The default is <code class="literal">on</code>.102       </p></dd><dt id="GUC-ENABLE-PARTITION-PRUNING"><span class="term"><code class="varname">enable_partition_pruning</code> (<code class="type">boolean</code>)103       <a id="id-1.6.7.10.2.3.15.1.3" class="indexterm"></a>104      </span> <a href="#GUC-ENABLE-PARTITION-PRUNING" class="id_link">#</a></dt><dd><p>105        Enables or disables the query planner's ability to eliminate a106        partitioned table's partitions from query plans.  This also controls107        the planner's ability to generate query plans which allow the query108        executor to remove (ignore) partitions during query execution.  The109        default is <code class="literal">on</code>.110        See <a class="xref" href="ddl-partitioning.html#DDL-PARTITION-PRUNING" title="5.11.4. Partition Pruning">Section 5.11.4</a> for details.111       </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-JOIN"><span class="term"><code class="varname">enable_partitionwise_join</code> (<code class="type">boolean</code>)112      <a id="id-1.6.7.10.2.3.16.1.3" class="indexterm"></a>113      </span> <a href="#GUC-ENABLE-PARTITIONWISE-JOIN" class="id_link">#</a></dt><dd><p>114        Enables or disables the query planner's use of partitionwise join,115        which allows a join between partitioned tables to be performed by116        joining the matching partitions.  Partitionwise join currently applies117        only when the join conditions include all the partition keys, which118        must be of the same data type and have one-to-one matching sets of119        child partitions.  Because partitionwise join planning can use120        significantly more CPU time and memory during planning, the default is121        <code class="literal">off</code>.122       </p></dd><dt id="GUC-ENABLE-PARTITIONWISE-AGGREGATE"><span class="term"><code class="varname">enable_partitionwise_aggregate</code> (<code class="type">boolean</code>)123      <a id="id-1.6.7.10.2.3.17.1.3" class="indexterm"></a>124      </span> <a href="#GUC-ENABLE-PARTITIONWISE-AGGREGATE" class="id_link">#</a></dt><dd><p>125        Enables or disables the query planner's use of partitionwise grouping126        or aggregation, which allows grouping or aggregation on partitioned127        tables to be performed separately for each partition.  If the128        <code class="literal">GROUP BY</code> clause does not include the partition129        keys, only partial aggregation can be performed on a per-partition130        basis, and finalization must be performed later.  Because131        partitionwise grouping or aggregation can use significantly more CPU132        time and memory during planning, the default is133        <code class="literal">off</code>.134       </p></dd><dt id="GUC-ENABLE-PRESORTED-AGGREGATE"><span class="term"><code class="varname">enable_presorted_aggregate</code> (<code class="type">boolean</code>)135      <a id="id-1.6.7.10.2.3.18.1.3" class="indexterm"></a>136      </span> <a href="#GUC-ENABLE-PRESORTED-AGGREGATE" class="id_link">#</a></dt><dd><p>137        Controls if the query planner will produce a plan which will provide138        rows which are presorted in the order required for the query's139        <code class="literal">ORDER BY</code> / <code class="literal">DISTINCT</code> aggregate140        functions.  When disabled, the query planner will produce a plan which141        will always require the executor to perform a sort before performing142        aggregation of each aggregate function containing an143        <code class="literal">ORDER BY</code> or <code class="literal">DISTINCT</code> clause.144        When enabled, the planner will try to produce a more efficient plan145        which provides input to the aggregate functions which is presorted in146        the order they require for aggregation.  The default value is147        <code class="literal">on</code>.148       </p></dd><dt id="GUC-ENABLE-SEQSCAN"><span class="term"><code class="varname">enable_seqscan</code> (<code class="type">boolean</code>)149      <a id="id-1.6.7.10.2.3.19.1.3" class="indexterm"></a>150      <a id="id-1.6.7.10.2.3.19.1.4" class="indexterm"></a>151      </span> <a href="#GUC-ENABLE-SEQSCAN" class="id_link">#</a></dt><dd><p>152        Enables or disables the query planner's use of sequential scan153        plan types. It is impossible to suppress sequential scans154        entirely, but turning this variable off discourages the planner155        from using one if there are other methods available. The156        default is <code class="literal">on</code>.157       </p></dd><dt id="GUC-ENABLE-SORT"><span class="term"><code class="varname">enable_sort</code> (<code class="type">boolean</code>)158      <a id="id-1.6.7.10.2.3.20.1.3" class="indexterm"></a>159      </span> <a href="#GUC-ENABLE-SORT" class="id_link">#</a></dt><dd><p>160        Enables or disables the query planner's use of explicit sort161        steps. It is impossible to suppress explicit sorts entirely,162        but turning this variable off discourages the planner from163        using one if there are other methods available. The default164        is <code class="literal">on</code>.165       </p></dd><dt id="GUC-ENABLE-TIDSCAN"><span class="term"><code class="varname">enable_tidscan</code> (<code class="type">boolean</code>)166      <a id="id-1.6.7.10.2.3.21.1.3" class="indexterm"></a>167      </span> <a href="#GUC-ENABLE-TIDSCAN" class="id_link">#</a></dt><dd><p>168        Enables or disables the query planner's use of <acronym class="acronym">TID</acronym>169        scan plan types. The default is <code class="literal">on</code>.170       </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-CONSTANTS"><div class="titlepage"><div><div><h3 class="title">20.7.2. Planner Cost Constants <a href="#RUNTIME-CONFIG-QUERY-CONSTANTS" class="id_link">#</a></h3></div></div></div><p>171     The <em class="firstterm">cost</em> variables described in this section are measured172     on an arbitrary scale.  Only their relative values matter, hence173     scaling them all up or down by the same factor will result in no change174     in the planner's choices.  By default, these cost variables are based on175     the cost of sequential page fetches; that is,176     <code class="varname">seq_page_cost</code> is conventionally set to <code class="literal">1.0</code>177     and the other cost variables are set with reference to that.  But178     you can use a different scale if you prefer, such as actual execution179     times in milliseconds on a particular machine.180    </p><div class="note"><h3 class="title">Note</h3><p>181     Unfortunately, there is no well-defined method for determining ideal182     values for the cost variables.  They are best treated as averages over183     the entire mix of queries that a particular installation will receive.  This184     means that changing them on the basis of just a few experiments is very185     risky.186    </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>)187      <a id="id-1.6.7.10.3.4.1.1.3" class="indexterm"></a>188      </span> <a href="#GUC-SEQ-PAGE-COST" class="id_link">#</a></dt><dd><p>189        Sets the planner's estimate of the cost of a disk page fetch190        that is part of a series of sequential fetches.  The default is 1.0.191        This value can be overridden for tables and indexes in a particular192        tablespace by setting the tablespace parameter of the same name193        (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>).194       </p></dd><dt id="GUC-RANDOM-PAGE-COST"><span class="term"><code class="varname">random_page_cost</code> (<code class="type">floating point</code>)195      <a id="id-1.6.7.10.3.4.2.1.3" class="indexterm"></a>196      </span> <a href="#GUC-RANDOM-PAGE-COST" class="id_link">#</a></dt><dd><p>197        Sets the planner's estimate of the cost of a198        non-sequentially-fetched disk page.  The default is 4.0.199        This value can be overridden for tables and indexes in a particular200        tablespace by setting the tablespace parameter of the same name201        (see <a class="xref" href="sql-altertablespace.html" title="ALTER TABLESPACE"><span class="refentrytitle">ALTER TABLESPACE</span></a>).202       </p><p>203        Reducing this value relative to <code class="varname">seq_page_cost</code>204        will cause the system to prefer index scans; raising it will205        make index scans look relatively more expensive.  You can raise206        or lower both values together to change the importance of disk I/O207        costs relative to CPU costs, which are described by the following208        parameters.209       </p><p>210        Random access to mechanical disk storage is normally much more expensive211        than four times sequential access.  However, a lower default is used212        (4.0) because the majority of random accesses to disk, such as indexed213        reads, are assumed to be in cache.  The default value can be thought of214        as modeling random access as 40 times slower than sequential, while215        expecting 90% of random reads to be cached.216       </p><p>217        If you believe a 90% cache rate is an incorrect assumption218        for your workload, you can increase random_page_cost to better219        reflect the true cost of random storage reads. Correspondingly,220        if your data is likely to be completely in cache, such as when221        the database is smaller than the total server memory, decreasing222        random_page_cost can be appropriate.  Storage that has a low random223        read cost relative to sequential, e.g., solid-state drives, might224        also be better modeled with a lower value for random_page_cost,225        e.g., <code class="literal">1.1</code>.226       </p><div class="tip"><h3 class="title">Tip</h3><p>227         Although the system will let you set <code class="varname">random_page_cost</code> to228         less than <code class="varname">seq_page_cost</code>, it is not physically sensible229         to do so.  However, setting them equal makes sense if the database230         is entirely cached in RAM, since in that case there is no penalty231         for touching pages out of sequence.  Also, in a heavily-cached232         database you should lower both values relative to the CPU parameters,233         since the cost of fetching a page already in RAM is much smaller234         than it would normally be.235        </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>)236      <a id="id-1.6.7.10.3.4.3.1.3" class="indexterm"></a>237      </span> <a href="#GUC-CPU-TUPLE-COST" class="id_link">#</a></dt><dd><p>238        Sets the planner's estimate of the cost of processing239        each row during a query.240        The default is 0.01.241       </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>)242      <a id="id-1.6.7.10.3.4.4.1.3" class="indexterm"></a>243      </span> <a href="#GUC-CPU-INDEX-TUPLE-COST" class="id_link">#</a></dt><dd><p>244        Sets the planner's estimate of the cost of processing245        each index entry during an index scan.246        The default is 0.005.247       </p></dd><dt id="GUC-CPU-OPERATOR-COST"><span class="term"><code class="varname">cpu_operator_cost</code> (<code class="type">floating point</code>)248      <a id="id-1.6.7.10.3.4.5.1.3" class="indexterm"></a>249      </span> <a href="#GUC-CPU-OPERATOR-COST" class="id_link">#</a></dt><dd><p>250        Sets the planner's estimate of the cost of processing each251        operator or function executed during a query.252        The default is 0.0025.253       </p></dd><dt id="GUC-PARALLEL-SETUP-COST"><span class="term"><code class="varname">parallel_setup_cost</code> (<code class="type">floating point</code>)254      <a id="id-1.6.7.10.3.4.6.1.3" class="indexterm"></a>255      </span> <a href="#GUC-PARALLEL-SETUP-COST" class="id_link">#</a></dt><dd><p>256        Sets the planner's estimate of the cost of launching parallel worker257        processes.258        The default is 1000.259       </p></dd><dt id="GUC-PARALLEL-TUPLE-COST"><span class="term"><code class="varname">parallel_tuple_cost</code> (<code class="type">floating point</code>)260      <a id="id-1.6.7.10.3.4.7.1.3" class="indexterm"></a>261      </span> <a href="#GUC-PARALLEL-TUPLE-COST" class="id_link">#</a></dt><dd><p>262        Sets the planner's estimate of the cost of transferring one tuple263        from a parallel worker process to another process.264        The default is 0.1.265       </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>)266      <a id="id-1.6.7.10.3.4.8.1.3" class="indexterm"></a>267      </span> <a href="#GUC-MIN-PARALLEL-TABLE-SCAN-SIZE" class="id_link">#</a></dt><dd><p>268        Sets the minimum amount of table data that must be scanned in order269        for a parallel scan to be considered.  For a parallel sequential scan,270        the amount of table data scanned is always equal to the size of the271        table, but when indexes are used the amount of table data272        scanned will normally be less.273        If this value is specified without units, it is taken as blocks,274        that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.275        The default is 8 megabytes (<code class="literal">8MB</code>).276       </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>)277      <a id="id-1.6.7.10.3.4.9.1.3" class="indexterm"></a>278      </span> <a href="#GUC-MIN-PARALLEL-INDEX-SCAN-SIZE" class="id_link">#</a></dt><dd><p>279        Sets the minimum amount of index data that must be scanned in order280        for a parallel scan to be considered.  Note that a parallel index scan281        typically won't touch the entire index; it is the number of pages282        which the planner believes will actually be touched by the scan which283        is relevant.  This parameter is also used to decide whether a284        particular index can participate in a parallel vacuum.  See285        <a class="xref" href="sql-vacuum.html" title="VACUUM"><span class="refentrytitle">VACUUM</span></a>.286        If this value is specified without units, it is taken as blocks,287        that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.288        The default is 512 kilobytes (<code class="literal">512kB</code>).289       </p></dd><dt id="GUC-EFFECTIVE-CACHE-SIZE"><span class="term"><code class="varname">effective_cache_size</code> (<code class="type">integer</code>)290      <a id="id-1.6.7.10.3.4.10.1.3" class="indexterm"></a>291      </span> <a href="#GUC-EFFECTIVE-CACHE-SIZE" class="id_link">#</a></dt><dd><p>292        Sets the planner's assumption about the effective size of the293        disk cache that is available to a single query.  This is294        factored into estimates of the cost of using an index; a295        higher value makes it more likely index scans will be used, a296        lower value makes it more likely sequential scans will be297        used. When setting this parameter you should consider both298        <span class="productname">PostgreSQL</span>'s shared buffers and the299        portion of the kernel's disk cache that will be used for300        <span class="productname">PostgreSQL</span> data files, though some301        data might exist in both places. Also, take302        into account the expected number of concurrent queries on different303        tables, since they will have to share the available304        space.  This parameter has no effect on the size of shared305        memory allocated by <span class="productname">PostgreSQL</span>, nor306        does it reserve kernel disk cache; it is used only for estimation307        purposes.  The system also does not assume data remains in308        the disk cache between queries.309        If this value is specified without units, it is taken as blocks,310        that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.311        The default is 4 gigabytes (<code class="literal">4GB</code>).312        (If <code class="symbol">BLCKSZ</code> is not 8kB, the default value scales313        proportionally to it.)314       </p></dd><dt id="GUC-JIT-ABOVE-COST"><span class="term"><code class="varname">jit_above_cost</code> (<code class="type">floating point</code>)315      <a id="id-1.6.7.10.3.4.11.1.3" class="indexterm"></a>316      </span> <a href="#GUC-JIT-ABOVE-COST" class="id_link">#</a></dt><dd><p>317        Sets the query cost above which JIT compilation is activated, if318        enabled (see <a class="xref" href="jit.html" title="Chapter 32. Just-in-Time Compilation (JIT)">Chapter 32</a>).319        Performing <acronym class="acronym">JIT</acronym> costs planning time but can320        accelerate query execution.321        Setting this to <code class="literal">-1</code> disables JIT compilation.322        The default is <code class="literal">100000</code>.323       </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>)324      <a id="id-1.6.7.10.3.4.12.1.3" class="indexterm"></a>325      </span> <a href="#GUC-JIT-INLINE-ABOVE-COST" class="id_link">#</a></dt><dd><p>326        Sets the query cost above which JIT compilation attempts to inline327        functions and operators.  Inlining adds planning time, but can328        improve execution speed.  It is not meaningful to set this to less329        than <code class="varname">jit_above_cost</code>.330        Setting this to <code class="literal">-1</code> disables inlining.331        The default is <code class="literal">500000</code>.332       </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>)333      <a id="id-1.6.7.10.3.4.13.1.3" class="indexterm"></a>334      </span> <a href="#GUC-JIT-OPTIMIZE-ABOVE-COST" class="id_link">#</a></dt><dd><p>335        Sets the query cost above which JIT compilation applies expensive336        optimizations.  Such optimization adds planning time, but can improve337        execution speed.  It is not meaningful to set this to less338        than <code class="varname">jit_above_cost</code>, and it is unlikely to be339        beneficial to set it to more340        than <code class="varname">jit_inline_above_cost</code>.341        Setting this to <code class="literal">-1</code> disables expensive optimizations.342        The default is <code class="literal">500000</code>.343       </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-GEQO"><div class="titlepage"><div><div><h3 class="title">20.7.3. Genetic Query Optimizer <a href="#RUNTIME-CONFIG-QUERY-GEQO" class="id_link">#</a></h3></div></div></div><p>344      The genetic query optimizer (GEQO) is an algorithm that does query345      planning using heuristic searching.  This reduces planning time for346      complex queries (those joining many relations), at the cost of producing347      plans that are sometimes inferior to those found by the normal348      exhaustive-search algorithm.349      For more information see <a class="xref" href="geqo.html" title="Chapter 62. Genetic Query Optimizer">Chapter 62</a>.350     </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-GEQO"><span class="term"><code class="varname">geqo</code> (<code class="type">boolean</code>)351      <a id="id-1.6.7.10.4.3.1.1.3" class="indexterm"></a>352      <a id="id-1.6.7.10.4.3.1.1.4" class="indexterm"></a>353      <a id="id-1.6.7.10.4.3.1.1.5" class="indexterm"></a>354      </span> <a href="#GUC-GEQO" class="id_link">#</a></dt><dd><p>355        Enables or disables genetic query optimization.356        This is on by default.  It is usually best not to turn it off in357        production; the <code class="varname">geqo_threshold</code> variable provides358        more granular control of GEQO.359       </p></dd><dt id="GUC-GEQO-THRESHOLD"><span class="term"><code class="varname">geqo_threshold</code> (<code class="type">integer</code>)360      <a id="id-1.6.7.10.4.3.2.1.3" class="indexterm"></a>361      </span> <a href="#GUC-GEQO-THRESHOLD" class="id_link">#</a></dt><dd><p>362        Use genetic query optimization to plan queries with at least363        this many <code class="literal">FROM</code> items involved. (Note that a364        <code class="literal">FULL OUTER JOIN</code> construct counts as only one <code class="literal">FROM</code>365        item.) The default is 12. For simpler queries it is usually best366        to use the regular, exhaustive-search planner, but for queries with367        many tables the exhaustive search takes too long, often368        longer than the penalty of executing a suboptimal plan.  Thus,369        a threshold on the size of the query is a convenient way to manage370        use of GEQO.371       </p></dd><dt id="GUC-GEQO-EFFORT"><span class="term"><code class="varname">geqo_effort</code> (<code class="type">integer</code>)372      <a id="id-1.6.7.10.4.3.3.1.3" class="indexterm"></a>373      </span> <a href="#GUC-GEQO-EFFORT" class="id_link">#</a></dt><dd><p>374        Controls the trade-off between planning time and query plan375        quality in GEQO. This variable must be an integer in the376        range from 1 to 10. The default value is five. Larger values377        increase the time spent doing query planning, but also378        increase the likelihood that an efficient query plan will be379        chosen.380       </p><p>381        <code class="varname">geqo_effort</code> doesn't actually do anything382        directly; it is only used to compute the default values for383        the other variables that influence GEQO behavior (described384        below). If you prefer, you can set the other parameters by385        hand instead.386       </p></dd><dt id="GUC-GEQO-POOL-SIZE"><span class="term"><code class="varname">geqo_pool_size</code> (<code class="type">integer</code>)387      <a id="id-1.6.7.10.4.3.4.1.3" class="indexterm"></a>388      </span> <a href="#GUC-GEQO-POOL-SIZE" class="id_link">#</a></dt><dd><p>389        Controls the pool size used by GEQO, that is the390        number of individuals in the genetic population.  It must be391        at least two, and useful values are typically 100 to 1000.  If392        it is set to zero (the default setting) then a suitable393        value is chosen based on <code class="varname">geqo_effort</code> and394        the number of tables in the query.395       </p></dd><dt id="GUC-GEQO-GENERATIONS"><span class="term"><code class="varname">geqo_generations</code> (<code class="type">integer</code>)396      <a id="id-1.6.7.10.4.3.5.1.3" class="indexterm"></a>397      </span> <a href="#GUC-GEQO-GENERATIONS" class="id_link">#</a></dt><dd><p>398        Controls the number of generations used by GEQO, that is399        the number of iterations of the algorithm.  It must400        be at least one, and useful values are in the same range as401        the pool size.  If it is set to zero (the default setting)402        then a suitable value is chosen based on403        <code class="varname">geqo_pool_size</code>.404       </p></dd><dt id="GUC-GEQO-SELECTION-BIAS"><span class="term"><code class="varname">geqo_selection_bias</code> (<code class="type">floating point</code>)405      <a id="id-1.6.7.10.4.3.6.1.3" class="indexterm"></a>406      </span> <a href="#GUC-GEQO-SELECTION-BIAS" class="id_link">#</a></dt><dd><p>407        Controls the selection bias used by GEQO. The selection bias408        is the selective pressure within the population. Values can be409        from 1.50 to 2.00; the latter is the default.410       </p></dd><dt id="GUC-GEQO-SEED"><span class="term"><code class="varname">geqo_seed</code> (<code class="type">floating point</code>)411      <a id="id-1.6.7.10.4.3.7.1.3" class="indexterm"></a>412      </span> <a href="#GUC-GEQO-SEED" class="id_link">#</a></dt><dd><p>413        Controls the initial value of the random number generator used414        by GEQO to select random paths through the join order search space.415        The value can range from zero (the default) to one.  Varying the416        value changes the set of join paths explored, and may result in a417        better or worse best path being found.418       </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-QUERY-OTHER"><div class="titlepage"><div><div><h3 class="title">20.7.4. Other Planner Options <a href="#RUNTIME-CONFIG-QUERY-OTHER" class="id_link">#</a></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>)419      <a id="id-1.6.7.10.5.2.1.1.3" class="indexterm"></a>420      </span> <a href="#GUC-DEFAULT-STATISTICS-TARGET" class="id_link">#</a></dt><dd><p>421        Sets the default statistics target for table columns without422        a column-specific target set via <code class="command">ALTER TABLE423        SET STATISTICS</code>.  Larger values increase the time needed to424        do <code class="command">ANALYZE</code>, but might improve the quality of the425        planner's estimates. The default is 100. For more information426        on the use of statistics by the <span class="productname">PostgreSQL</span>427        query planner, refer to <a class="xref" href="planner-stats.html" title="14.2. Statistics Used by the Planner">Section 14.2</a>.428       </p></dd><dt id="GUC-CONSTRAINT-EXCLUSION"><span class="term"><code class="varname">constraint_exclusion</code> (<code class="type">enum</code>)429      <a id="id-1.6.7.10.5.2.2.1.3" class="indexterm"></a>430      <a id="id-1.6.7.10.5.2.2.1.4" class="indexterm"></a>431      </span> <a href="#GUC-CONSTRAINT-EXCLUSION" class="id_link">#</a></dt><dd><p>432        Controls the query planner's use of table constraints to433        optimize queries.434        The allowed values of <code class="varname">constraint_exclusion</code> are435        <code class="literal">on</code> (examine constraints for all tables),436        <code class="literal">off</code> (never examine constraints), and437        <code class="literal">partition</code> (examine constraints only for inheritance438        child tables and <code class="literal">UNION ALL</code> subqueries).439        <code class="literal">partition</code> is the default setting.440        It is often used with traditional inheritance trees to improve441        performance.442      </p><p>443        When this parameter allows it for a particular table, the planner444        compares query conditions with the table's <code class="literal">CHECK</code>445        constraints, and omits scanning tables for which the conditions446        contradict the constraints.  For example:447 448</p><pre class="programlisting">449CREATE TABLE parent(key integer, ...);450CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);451CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);452...453SELECT * FROM parent WHERE key = 2400;454</pre><p>455 456        With constraint exclusion enabled, this <code class="command">SELECT</code>457        will not scan <code class="structname">child1000</code> at all, improving performance.458       </p><p>459        Currently, constraint exclusion is enabled by default460        only for cases that are often used to implement table partitioning via461        inheritance trees.  Turning it on for all tables imposes extra462        planning overhead that is quite noticeable on simple queries, and most463        often will yield no benefit for simple queries.  If you have no464        tables that are partitioned using traditional inheritance, you might465        prefer to turn it off entirely.  (Note that the equivalent feature for466        partitioned tables is controlled by a separate parameter,467        <a class="xref" href="runtime-config-query.html#GUC-ENABLE-PARTITION-PRUNING">enable_partition_pruning</a>.)468       </p><p>469        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> for470        more information on using constraint exclusion to implement471        partitioning.472       </p></dd><dt id="GUC-CURSOR-TUPLE-FRACTION"><span class="term"><code class="varname">cursor_tuple_fraction</code> (<code class="type">floating point</code>)473      <a id="id-1.6.7.10.5.2.3.1.3" class="indexterm"></a>474      </span> <a href="#GUC-CURSOR-TUPLE-FRACTION" class="id_link">#</a></dt><dd><p>475        Sets the planner's estimate of the fraction of a cursor's rows that476        will be retrieved.  The default is 0.1.  Smaller values of this477        setting bias the planner towards using <span class="quote">“<span class="quote">fast start</span>”</span> plans478        for cursors, which will retrieve the first few rows quickly while479        perhaps taking a long time to fetch all rows.  Larger values480        put more emphasis on the total estimated time.  At the maximum481        setting of 1.0, cursors are planned exactly like regular queries,482        considering only the total estimated time and not how soon the483        first rows might be delivered.484       </p></dd><dt id="GUC-FROM-COLLAPSE-LIMIT"><span class="term"><code class="varname">from_collapse_limit</code> (<code class="type">integer</code>)485      <a id="id-1.6.7.10.5.2.4.1.3" class="indexterm"></a>486      </span> <a href="#GUC-FROM-COLLAPSE-LIMIT" class="id_link">#</a></dt><dd><p>487        The planner will merge sub-queries into upper queries if the488        resulting <code class="literal">FROM</code> list would have no more than489        this many items.  Smaller values reduce planning time but might490        yield inferior query plans.  The default is eight.491        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>.492       </p><p>493        Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more494        may trigger use of the GEQO planner, resulting in non-optimal495        plans.  See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="20.7.3. Genetic Query Optimizer">Section 20.7.3</a>.496       </p></dd><dt id="GUC-JIT"><span class="term"><code class="varname">jit</code> (<code class="type">boolean</code>)497      <a id="id-1.6.7.10.5.2.5.1.3" class="indexterm"></a>498      </span> <a href="#GUC-JIT" class="id_link">#</a></dt><dd><p>499        Determines whether <acronym class="acronym">JIT</acronym> compilation may be used by500        <span class="productname">PostgreSQL</span>, if available (see <a class="xref" href="jit.html" title="Chapter 32. Just-in-Time Compilation (JIT)">Chapter 32</a>).501        The default is <code class="literal">on</code>.502       </p></dd><dt id="GUC-JOIN-COLLAPSE-LIMIT"><span class="term"><code class="varname">join_collapse_limit</code> (<code class="type">integer</code>)503      <a id="id-1.6.7.10.5.2.6.1.3" class="indexterm"></a>504      </span> <a href="#GUC-JOIN-COLLAPSE-LIMIT" class="id_link">#</a></dt><dd><p>505        The planner will rewrite explicit <code class="literal">JOIN</code>506        constructs (except <code class="literal">FULL JOIN</code>s) into lists of507        <code class="literal">FROM</code> items whenever a list of no more than this many items508        would result.  Smaller values reduce planning time but might509        yield inferior query plans.510       </p><p>511        By default, this variable is set the same as512        <code class="varname">from_collapse_limit</code>, which is appropriate513        for most uses. Setting it to 1 prevents any reordering of514        explicit <code class="literal">JOIN</code>s. Thus, the explicit join order515        specified in the query will be the actual order in which the516        relations are joined. Because the query planner does not always choose517        the optimal join order, advanced users can elect to518        temporarily set this variable to 1, and then specify the join519        order they desire explicitly.520        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>.521       </p><p>522        Setting this value to <a class="xref" href="runtime-config-query.html#GUC-GEQO-THRESHOLD">geqo_threshold</a> or more523        may trigger use of the GEQO planner, resulting in non-optimal524        plans.  See <a class="xref" href="runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO" title="20.7.3. Genetic Query Optimizer">Section 20.7.3</a>.525       </p></dd><dt id="GUC-PLAN-CACHE-MODE"><span class="term"><code class="varname">plan_cache_mode</code> (<code class="type">enum</code>)526      <a id="id-1.6.7.10.5.2.7.1.3" class="indexterm"></a>527      </span> <a href="#GUC-PLAN-CACHE-MODE" class="id_link">#</a></dt><dd><p>528        Prepared statements (either explicitly prepared or implicitly529        generated, for example by PL/pgSQL) can be executed using custom or530        generic plans.  Custom plans are made afresh for each execution531        using its specific set of parameter values, while generic plans do532        not rely on the parameter values and can be re-used across533        executions.  Thus, use of a generic plan saves planning time, but if534        the ideal plan depends strongly on the parameter values then a535        generic plan may be inefficient.  The choice between these options536        is normally made automatically, but it can be overridden537        with <code class="varname">plan_cache_mode</code>.538        The allowed values are <code class="literal">auto</code> (the default),539        <code class="literal">force_custom_plan</code> and540        <code class="literal">force_generic_plan</code>.541        This setting is considered when a cached plan is to be executed,542        not when it is prepared.543        For more information see <a class="xref" href="sql-prepare.html" title="PREPARE"><span class="refentrytitle">PREPARE</span></a>.544       </p></dd><dt id="GUC-RECURSIVE-WORKTABLE-FACTOR"><span class="term"><code class="varname">recursive_worktable_factor</code> (<code class="type">floating point</code>)545      <a id="id-1.6.7.10.5.2.8.1.3" class="indexterm"></a>546      </span> <a href="#GUC-RECURSIVE-WORKTABLE-FACTOR" class="id_link">#</a></dt><dd><p>547        Sets the planner's estimate of the average size of the working548        table of a <a class="link" href="queries-with.html#QUERIES-WITH-RECURSIVE" title="7.8.2. Recursive Queries">recursive549        query</a>, as a multiple of the estimated size of the initial550        non-recursive term of the query.  This helps the planner choose551        the most appropriate method for joining the working table to the552        query's other tables.553        The default value is <code class="literal">10.0</code>.  A smaller value554        such as <code class="literal">1.0</code> can be helpful when the recursion555        has low <span class="quote">“<span class="quote">fan-out</span>”</span> from one step to the next, as for556        example in shortest-path queries.  Graph analytics queries may557        benefit from larger-than-default values.558       </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" title="20.6. Replication">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-logging.html" title="20.8. Error Reporting and Logging">Next</a></td></tr><tr><td width="40%" align="left" valign="top">20.6. Replication </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 20.8. Error Reporting and Logging</td></tr></table></div></body></html>
codekingpro/portable-devtools · Team Ai