Home • Explore • Blog • CI
☰



postgresql
89th chunk of `doc/src/sgml/config.sgml`
8586a8ff3a634900932adeb38c420b78e084f27693e539ef0000000100000fa0
 particular
        tablespace by setting the tablespace parameter of the same name
        (see <xref linkend="sql-altertablespace"/>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-random-page-cost" xreflabel="random_page_cost">
      <term><varname>random_page_cost</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>random_page_cost</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of a
        non-sequentially-fetched disk page.  The default is 4.0.
        This value can be overridden for tables and indexes in a particular
        tablespace by setting the tablespace parameter of the same name
        (see <xref linkend="sql-altertablespace"/>).
       </para>

       <para>
        Reducing this value relative to <varname>seq_page_cost</varname>
        will cause the system to prefer index scans; raising it will
        make index scans look relatively more expensive.  You can raise
        or lower both values together to change the importance of disk I/O
        costs relative to CPU costs, which are described by the following
        parameters.
       </para>

       <para>
        Random access to mechanical disk storage is normally much more expensive
        than four times sequential access.  However, a lower default is used
        (4.0) because the majority of random accesses to disk, such as indexed
        reads, are assumed to be in cache.  The default value can be thought of
        as modeling random access as 40 times slower than sequential, while
        expecting 90% of random reads to be cached.
       </para>

       <para>
        If you believe a 90% cache rate is an incorrect assumption
        for your workload, you can increase random_page_cost to better
        reflect the true cost of random storage reads. Correspondingly,
        if your data is likely to be completely in cache, such as when
        the database is smaller than the total server memory, decreasing
        random_page_cost can be appropriate.  Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might
        also be better modeled with a lower value for random_page_cost,
        e.g., <literal>1.1</literal>.
       </para>

       <tip>
        <para>
         Although the system will let you set <varname>random_page_cost</varname> to
         less than <varname>seq_page_cost</varname>, it is not physically sensible
         to do so.  However, setting them equal makes sense if the database
         is entirely cached in RAM, since in that case there is no penalty
         for touching pages out of sequence.  Also, in a heavily-cached
         database you should lower both values relative to the CPU parameters,
         since the cost of fetching a page already in RAM is much smaller
         than it would normally be.
        </para>
       </tip>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-cpu-tuple-cost" xreflabel="cpu_tuple_cost">
      <term><varname>cpu_tuple_cost</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>cpu_tuple_cost</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of processing
        each row during a query.
        The default is 0.01.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-cpu-index-tuple-cost" xreflabel="cpu_index_tuple_cost">
      <term><varname>cpu_index_tuple_cost</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>cpu_index_tuple_cost</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of processing
        each index entry during an index scan.
Title: Planner Cost Constants: Random Page Cost and CPU Costs
Summary
This section further elaborates on planner cost constants, specifically `random_page_cost` and CPU costs. It explains how adjusting `random_page_cost` relative to `seq_page_cost` influences the preference for index scans. It notes the default value (4.0) assumes a 90% cache rate for random accesses and provides guidance on adjusting it based on workload and storage type (e.g., solid-state drives). It also details `cpu_tuple_cost` (cost of processing each row, default 0.01).