the maximum number of these tries. This option can be combined with
        the <option>--latency-limit</option> option which limits the total time
        of all transaction tries; moreover, you cannot use an unlimited number
        of tries (<literal>--max-tries=0</literal>) without
        <option>--latency-limit</option> or <option>--time</option>.
        The default value is 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-progress-timestamp">
      <term><option>--progress-timestamp</option></term>
      <listitem>
       <para>
        When showing progress (option <option>-P</option>), use a timestamp
        (Unix epoch) instead of the number of seconds since the
        beginning of the run.  The unit is in seconds, with millisecond
        precision after the dot.
        This helps compare logs generated by various tools.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-random-seed">
      <term><option>--random-seed=</option><replaceable>seed</replaceable></term>
      <listitem>
       <para>
        Set random generator seed.  Seeds the system random number generator,
        which then produces a sequence of initial generator states, one for
        each thread.
        Values for <replaceable>seed</replaceable> may be:
        <literal>time</literal> (the default, the seed is based on the current time),
        <literal>rand</literal> (use a strong random source, failing if none
        is available), or an unsigned decimal integer value.
        The random generator is invoked explicitly from a pgbench script
        (<literal>random...</literal> functions) or implicitly (for instance option
        <option>--rate</option> uses it to schedule transactions).
        When explicitly set, the value used for seeding is shown on the terminal.
        Any value allowed for <replaceable>seed</replaceable> may also be
        provided through the environment variable
        <literal>PGBENCH_RANDOM_SEED</literal>.
        To ensure that the provided seed impacts all possible uses, put this option
        first or use the environment variable.
      </para>
      <para>
        Setting the seed explicitly allows to reproduce a <command>pgbench</command>
        run exactly, as far as random numbers are concerned.
        As the random state is managed per thread, this means the exact same
        <command>pgbench</command> run for an identical invocation if there is one
        client per thread and there are no external or data dependencies.
        From a statistical viewpoint reproducing runs exactly is a bad idea because
        it can hide the performance variability or improve performance unduly,
        e.g., by hitting the same pages as a previous run.
        However, it may also be of great help for debugging, for instance
        re-running a tricky case which leads to an error.
        Use wisely.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-sampling-rate">
      <term><option>--sampling-rate=<replaceable>rate</replaceable></option></term>
      <listitem>
       <para>
        Sampling rate, used when writing data into the log, to reduce the
        amount of log generated. If this option is given, only the specified
        fraction of transactions are logged. 1.0 means all transactions will
        be logged, 0.05 means only 5% of the transactions will be logged.
       </para>
       <para>
        Remember to take the sampling rate into account when processing the
        log file. For example, when computing TPS values, you need to multiply
        the numbers accordingly (e.g., with 0.01 sample rate, you'll only get
        1/100 of the actual TPS).
       </para>
      </listitem>