considering a parameterized scan for use in the inside of a nestloop
       join.  Note that the cost estimates should still be for just one scan;
       a larger <parameter>loop_count</parameter> means that it may be appropriate
       to allow for some caching effects across multiple scans.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The last five parameters are pass-by-reference outputs:

   <variablelist>
    <varlistentry>
     <term><parameter>*indexStartupCost</parameter></term>
     <listitem>
      <para>
       Set to cost of index start-up processing
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><parameter>*indexTotalCost</parameter></term>
     <listitem>
      <para>
       Set to total cost of index processing
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><parameter>*indexSelectivity</parameter></term>
     <listitem>
      <para>
       Set to index selectivity
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><parameter>*indexCorrelation</parameter></term>
     <listitem>
      <para>
       Set to correlation coefficient between index scan order and
       underlying table's order
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><parameter>*indexPages</parameter></term>
     <listitem>
      <para>
       Set to number of index leaf pages
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   Note that cost estimate functions must be written in C, not in SQL or
   any available procedural language, because they must access internal
   data structures of the planner/optimizer.
  </para>

  <para>
   The index access costs should be computed using the parameters used by
   <filename>src/backend/optimizer/path/costsize.c</filename>: a sequential
   disk block fetch has cost <varname>seq_page_cost</varname>, a nonsequential fetch
   has cost <varname>random_page_cost</varname>, and the cost of processing one index
   row should usually be taken as <varname>cpu_index_tuple_cost</varname>.  In
   addition, an appropriate multiple of <varname>cpu_operator_cost</varname> should
   be charged for any comparison operators invoked during index processing
   (especially evaluation of the indexquals themselves).
  </para>

  <para>
   The access costs should include all disk and CPU costs associated with
   scanning the index itself, but <emphasis>not</emphasis> the costs of retrieving or
   processing the parent-table rows that are identified by the index.
  </para>

  <para>
   The <quote>start-up cost</quote> is the part of the total scan cost that
   must be expended before we can begin to fetch the first row.  For most
   indexes this can be taken as zero, but an index type with a high start-up
   cost might want to set it nonzero.
  </para>

  <para>
   The <parameter>indexSelectivity</parameter> should be set to the estimated fraction of the parent
   table rows that will be retrieved during the index scan.  In the case
   of a lossy query, this will typically be higher than the fraction of
   rows that