report
        includes the time since the beginning of the run, the TPS since the
        last report, and the transaction latency average, standard deviation,
        and the number of failed transactions since the last report. Under
        throttling (<option>-R</option>), the latency is computed with respect
        to the transaction scheduled start time, not the actual transaction
        beginning time, thus it also includes the average schedule lag time.
        When <option>--max-tries</option> is used to enable transaction retries
        after serialization/deadlock errors, the report includes the number of
        retried transactions and the sum of all retries.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-report-latencies">
      <term><option>-r</option></term>
      <term><option>--report-per-command</option></term>
      <listitem>
       <para>
        Report the following statistics for each command after the benchmark
        finishes: the average per-statement latency (execution time from the
        perspective of the client), the number of failures, and the number of
        retries after serialization or deadlock errors in this command.  The
        report displays retry statistics only if the
        <option>--max-tries</option> option is not equal to 1.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="pgbench-option-rate">
      <term><option>-R</option> <replaceable>rate</replaceable></term>
      <term><option>--rate=</option><replaceable>rate</replaceable></term>
      <listitem>
       <para>
        Execute transactions targeting the specified rate instead of running
        as fast as possible (the default).  The rate is given in transactions
        per second.  If the targeted rate is above the maximum possible rate,
        the rate limit won't impact the results.
       </para>
       <para>
        The rate is targeted by starting transactions along a
        Poisson-distributed schedule time line.  The expected start time
        schedule moves forward based on when the client first started, not
        when the previous transaction ended.  That approach means that when
        transactions go past their original scheduled end time, it is
        possible for later ones to catch up again.
       </para>
       <para>
        When throttling is active, the transaction latency reported at the
        end of the run is calculated from the scheduled start times, so it
        includes the time each transaction had to wait for the previous
        transaction to finish. The wait time is called the schedule lag time,
        and its average and maximum are also reported separately. The
        transaction latency with respect to the actual transaction start time,
        i.e., the time spent executing the transaction in the database, can be
        computed by subtracting the schedule lag time from the reported
        latency.
       </para>

       <para>
        If <option>--latency-limit</option> is used together with <option>--rate</option>,
        a transaction can lag behind so much that it is already over the
        latency limit when the previous transaction ends, because the latency
        is calculated from the scheduled start time. Such transactions are
        not sent to the server, but are skipped altogether and counted
        separately.
       </para>

       <para>
        A high schedule lag time is an indication that the system cannot
        process transactions at the specified rate, with the chosen number of
        clients and threads. When the average transaction execution time is
        longer than the scheduled interval between each transaction, each
        successive transaction will fall further behind, and the schedule lag
        time will keep increasing the longer the test run is. When that
        happens, you will have to reduce the specified transaction rate.
       </para>