</term>
      <listitem>
       <para>
        Sets the minimum amount of table data that must be scanned in order
        for a parallel scan to be considered.  For a parallel sequential scan,
        the amount of table data scanned is always equal to the size of the
        table, but when indexes are used the amount of table data
        scanned will normally be less.
        If this value is specified without units, it is taken as blocks,
        that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
        The default is 8 megabytes (<literal>8MB</literal>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-min-parallel-index-scan-size" xreflabel="min_parallel_index_scan_size">
      <term><varname>min_parallel_index_scan_size</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>min_parallel_index_scan_size</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the minimum amount of index data that must be scanned in order
        for a parallel scan to be considered.  Note that a parallel index scan
        typically won't touch the entire index; it is the number of pages
        which the planner believes will actually be touched by the scan which
        is relevant.  This parameter is also used to decide whether a
        particular index can participate in a parallel vacuum.  See
        <xref linkend="sql-vacuum"/>.
        If this value is specified without units, it is taken as blocks,
        that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
        The default is 512 kilobytes (<literal>512kB</literal>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-effective-cache-size" xreflabel="effective_cache_size">
      <term><varname>effective_cache_size</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>effective_cache_size</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the planner's assumption about the effective size of the
        disk cache that is available to a single query.  This is
        factored into estimates of the cost of using an index; a
        higher value makes it more likely index scans will be used, a
        lower value makes it more likely sequential scans will be
        used. When setting this parameter you should consider both
        <productname>PostgreSQL</productname>'s shared buffers and the
        portion of the kernel's disk cache that will be used for
        <productname>PostgreSQL</productname> data files, though some
        data might exist in both places. Also, take
        into account the expected number of concurrent queries on different
        tables, since they will have to share the available
        space.  This parameter has no effect on the size of shared
        memory allocated by <productname>PostgreSQL</productname>, nor
        does it reserve kernel disk cache; it is used only for estimation
        purposes.  The system also does not assume data remains in
        the disk cache between queries.
        If this value is specified without units, it is taken as blocks,
        that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
        The default is 4 gigabytes (<literal>4GB</literal>).
        (If <symbol>BLCKSZ</symbol> is not 8kB, the default value scales
        proportionally to it.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-jit-above-cost" xreflabel="jit_above_cost">
      <term><varname>jit_above_cost</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>jit_above_cost</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the query cost above which JIT compilation is activated, if
        enabled (see <xref linkend="jit"/>).
        Performing <acronym>JIT</acronym>