Home • Explore • Blog • CI
☰



postgresql
7th chunk of `doc/src/sgml/ref/pgbench.sgml`
85ced53e932420ae734e567a2744c0dff42bae0be41273d50000000100000fa9
 <term><option>--define=</option><replaceable>varname</replaceable><literal>=</literal><replaceable>value</replaceable></term>
      <listitem>
       <para>
        Define a variable for use by a custom script (see below).
        Multiple <option>-D</option> options are allowed.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-file">
      <term><option>-f</option> <replaceable>filename[@weight]</replaceable></term>
      <term><option>--file=</option><replaceable>filename[@weight]</replaceable></term>
      <listitem>
       <para>
        Add a transaction script read from <replaceable>filename</replaceable>
        to the list of scripts to be executed.
       </para>
       <para>
        Optionally, write an integer weight after <literal>@</literal> to
        adjust the probability of selecting this script versus other ones.
        The default weight is 1.
        (To use a script file name that includes an <literal>@</literal>
        character, append a weight so that there is no ambiguity, for
        example <literal>filen@me@1</literal>.)
        See below for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-jobs">
      <term><option>-j</option> <replaceable>threads</replaceable></term>
      <term><option>--jobs=</option><replaceable>threads</replaceable></term>
      <listitem>
       <para>
        Number of worker threads within <application>pgbench</application>.
        Using more than one thread can be helpful on multi-CPU machines.
        Clients are distributed as evenly as possible among available threads.
        Default is 1.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-log">
      <term><option>-l</option></term>
      <term><option>--log</option></term>
      <listitem>
       <para>
        Write information about each transaction to a log file.
        See below for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-latency-limit">
      <term><option>-L</option> <replaceable>limit</replaceable></term>
      <term><option>--latency-limit=</option><replaceable>limit</replaceable></term>
      <listitem>
       <para>
        Transactions that last more than <replaceable>limit</replaceable> milliseconds
        are counted and reported separately, as <firstterm>late</firstterm>.
       </para>
       <para>
        When throttling is used (<option>--rate=...</option>), transactions that
        lag behind schedule by more than <replaceable>limit</replaceable> ms, and thus
        have no hope of meeting the latency limit, are not sent to the server
        at all. They are counted and reported separately as
        <firstterm>skipped</firstterm>.
       </para>
       <para>
        When the <option>--max-tries</option> option is used, a transaction
        which fails due to a serialization anomaly or from a deadlock will not
        be retried if the total time of all its tries is greater than
        <replaceable>limit</replaceable> ms. To limit only the time of tries
        and not their number, use <literal>--max-tries=0</literal>. By
        default, the option <option>--max-tries</option> is set to 1 and
        transactions with serialization/deadlock errors are not retried. See
        <xref linkend="failures-and-retries"/> for more information about
        retrying such transactions.
       </para>
       </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-protocol">
      <term><option>-M</option> <replaceable>querymode</replaceable></term>
      <term><option>--protocol=</option><replaceable>querymode</replaceable></term>
      <listitem>
       <para>
        Protocol to use for submitting queries to the server:
          <itemizedlist>
           <listitem>
            <para><literal>simple</literal>: use simple query protocol.</para>
           </listitem>
           <listitem>
Title: pgbench Benchmarking Options: Custom Script Variables, File Inclusion, Threads, Logging, Latency Limits, and Protocol Selection
Summary
This section details pgbench benchmarking options including defining variables for custom scripts, adding transaction scripts from files with weighting, specifying the number of worker threads, enabling transaction logging, setting latency limits for identifying late or skipped transactions, and choosing the query protocol (simple, extended, prepared).