floating
       point value that is used as extra cost per-tuple for foreign-table
       scans on that server.  This represents the additional overhead of
       data transfer between servers.  You might increase or decrease this
       number to reflect higher or lower network delay to the remote server.
       The default value is <literal>0.2</literal>.
      </para>
     </listitem>
    </varlistentry>

   </variablelist>

   <para>
    When <literal>use_remote_estimate</literal> is true,
    <filename>postgres_fdw</filename> obtains row count and cost estimates from the
    remote server and then adds <literal>fdw_startup_cost</literal> and
    <literal>fdw_tuple_cost</literal> to the cost estimates.  When
    <literal>use_remote_estimate</literal> is false,
    <filename>postgres_fdw</filename> performs local row count and cost estimation
    and then adds <literal>fdw_startup_cost</literal> and
    <literal>fdw_tuple_cost</literal> to the cost estimates.  This local
    estimation is unlikely to be very accurate unless local copies of the
    remote table's statistics are available.  Running
    <xref linkend="sql-analyze"/> on the foreign table is the way to update
    the local statistics; this will perform a scan of the remote table and
    then calculate and store statistics just as though the table were local.
    Keeping local statistics can be a useful way to reduce per-query planning
    overhead for a remote table &mdash; but if the remote table is
    frequently updated, the local statistics will soon be obsolete.
   </para>

   <para>
    The following option controls how such an <command>ANALYZE</command>
    operation behaves:
   </para>

   <variablelist>

    <varlistentry>
     <term><literal>analyze_sampling</literal> (<type>string</type>)</term>
     <listitem>
      <para>
       This option, which can be specified for a foreign table or a foreign
       server, determines if <command>ANALYZE</command> on a foreign table
       samples the data on the remote side, or reads and transfers all data
       and performs the sampling locally. The supported values
       are <literal>off</literal>, <literal>random</literal>,
       <literal>system</literal>, <literal>bernoulli</literal>
       and <literal>auto</literal>. <literal>off</literal> disables remote
       sampling, so all data are transferred and sampled locally.
       <literal>random</literal> performs remote sampling using the
       <literal>random()</literal> function to choose returned rows,
       while <literal>system</literal> and <literal>bernoulli</literal> rely
       on the built-in <literal>TABLESAMPLE</literal> methods of those
       names. <literal>random</literal> works on all remote server versions,
       while <literal>TABLESAMPLE</literal> is supported only since 9.5.
       <literal>auto</literal> (the default) picks the recommended sampling
       method automatically; currently it means
       either <literal>bernoulli</literal> or <literal>random</literal>
       depending on the remote server version.
      </para>
     </listitem>
    </varlistentry>

   </variablelist>

  </sect3>

  <sect3 id="postgres-fdw-options-remote-execution">
   <title>Remote Execution Options</title>

   <para>
    By default, only <literal>WHERE</literal> clauses using built-in operators and
    functions will be considered for execution on the remote server.  Clauses
    involving non-built-in functions are checked locally after rows are
    fetched.  If such functions are available on the remote server and can be
    relied on to produce the same results as they do locally, performance can
    be improved by sending such <literal>WHERE</literal> clauses for remote
    execution.  This behavior can be controlled using the following option:
   </para>

   <variablelist>

    <varlistentry>
     <term><literal>extensions</literal> (<type>string</type>)</term>
     <listitem>
      <para>
       This option is a comma-separated list of names