transactions retried: 7667 (76.670%)
total number of retries: 45339
number of transactions above the 50.0 ms latency limit: 106/6317 (1.678 %)
latency average = 17.016 ms
latency stddev = 13.283 ms
initial connection time = 45.017 ms
tps = 186.792667 (without initial connection time)
statement latencies in milliseconds, failures and retries:
  0.006     0      0  \set aid random(1, 100000 * :scale)
  0.001     0      0  \set bid random(1, 1 * :scale)
  0.001     0      0  \set tid random(1, 10 * :scale)
  0.001     0      0  \set delta random(-5000, 5000)
  0.385     0      0  BEGIN;
  0.773     0      1  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
  0.624     0      0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
  1.098   320   3762  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
  0.582  3363  41576  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
  0.465     0      0  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
  1.933     0      0  END;
</screen></para>

  <para>
   If multiple script files are specified, all statistics are reported
   separately for each script file.
  </para>

  <para>
   Note that collecting the additional timing information needed for
   per-statement latency computation adds some overhead.  This will slow
   average execution speed and lower the computed TPS.  The amount
   of slowdown varies significantly depending on platform and hardware.
   Comparing average TPS values with and without latency reporting enabled
   is a good way to measure if the timing overhead is significant.
  </para>
 </refsect2>

 <refsect2 id="failures-and-retries" xreflabel="Failures and Serialization/Deadlock Retries">
  <title>Failures and Serialization/Deadlock Retries</title>

  <para>
   When executing <application>pgbench</application>, there are three main types
   of errors:
   <itemizedlist>
     <listitem>
       <para>
         Errors of the main program. They are the most serious and always result
         in an immediate exit from <application>pgbench</application> with the
         corresponding error message. They include:
         <itemizedlist>
           <listitem>
             <para>
               errors at the beginning of <application>pgbench</application>
               (e.g. an invalid option value);
             </para>
           </listitem>
           <listitem>
             <para>
               errors in the initialization mode (e.g. the query to create
               tables for built-in scripts fails);
             </para>
           </listitem>
           <listitem>
             <para>
               errors before starting threads (e.g. could not connect to the
               database server, syntax error in the meta command, thread
               creation failure);
             </para>
           </listitem>
           <listitem>
             <para>
               internal <application>pgbench</application> errors (which are
               supposed to never occur...).
             </para>
           </listitem>
         </itemizedlist></para>
     </listitem>
     <listitem>
       <para>
         Errors when the thread manages its clients (e.g. the client could not
         start a connection to the database server / the socket for connecting
         the client to the database server has become invalid). In such cases
         all clients of this thread stop while other threads continue to work.
         However, <option>--exit-on-abort</option> is specified, all of the
         threads stop immediately in this case.
       </para>
     </listitem>
     <listitem>
       <para>
         Direct client errors. They lead to immediate exit from
         <application>pgbench</application> with the corresponding error message
         in the case of an internal <application>pgbench</application>
         error (which are supposed to never