The format of the log is:

<synopsis>

<replaceable>client_id</replaceable> <replaceable>transaction_no</replaceable> <replaceable>time</replaceable> <replaceable>script_no</replaceable> <replaceable>time_epoch</replaceable> <replaceable>time_us</replaceable> <optional> <replaceable>schedule_lag</replaceable> </optional> <optional> <replaceable>retries</replaceable> </optional>

</synopsis>

where

<replaceable>client_id</replaceable> indicates which client session ran the transaction,

<replaceable>transaction_no</replaceable> counts how many transactions have been

run by that session,

<replaceable>time</replaceable> is the total elapsed transaction time in microseconds,

<replaceable>script_no</replaceable> identifies which script file was used (useful when

multiple scripts were specified with <option>-f</option> or <option>-b</option>),

and <replaceable>time_epoch</replaceable>/<replaceable>time_us</replaceable> are a

Unix-epoch time stamp and an offset

in microseconds (suitable for creating an ISO 8601

time stamp with fractional seconds) showing when

the transaction completed.

The <replaceable>schedule_lag</replaceable> field is the difference between the

transaction's scheduled start time, and the time it actually started, in

microseconds. It is only present when the <option>--rate</option> option is used.

<replaceable>retries</replaceable> is the sum of all retries after the

serialization or deadlock errors during the current script execution. It is

present only if the <option>--max-tries</option> option is not equal to 1.

format is used for the log files:

<synopsis>

<replaceable>interval_start</replaceable> <replaceable>num_transactions</replaceable> <replaceable>sum_latency</replaceable> <replaceable>sum_latency_2</replaceable> <replaceable>min_latency</replaceable> <replaceable>max_latency</replaceable>

<replaceable>sum_lag</replaceable> <replaceable>sum_lag_2</replaceable> <replaceable>min_lag</replaceable> <replaceable>max_lag</replaceable> <replaceable>skipped</replaceable>

<replaceable>retried</replaceable> <replaceable>retries</replaceable> <replaceable>failures</replaceable> <replaceable>serialization_failures</replaceable> <replaceable>deadlock_failures</replaceable>

</synopsis>

where

<replaceable>interval_start</replaceable> is the start of the interval (as a Unix

epoch time stamp),

<replaceable>num_transactions</replaceable> is the number of transactions

within the interval,

<replaceable>sum_latency</replaceable> is the sum of the transaction

latencies within the interval,

<replaceable>sum_latency_2</replaceable> is the sum of squares of the

transaction latencies within the interval,

<replaceable>min_latency</replaceable> is the minimum latency within the interval,

and

<replaceable>max_latency</replaceable> is the maximum latency within the interval,

<replaceable>failures</replaceable> is the number of transactions that ended

with a failed SQL command within the interval.

</para>

<para>

The next fields,

<replaceable>sum_lag</replaceable>, <replaceable>sum_lag_2</replaceable>, <replaceable>min_lag</replaceable>,

and <replaceable>max_lag</replaceable>, only meaningful if the <option>--rate</option>

option is used. Otherwise, they are all 0.0.

They provide statistics about the time each transaction had to wait for the

previous one to finish, i.e., the difference between each transaction's

scheduled start time and the time it actually started.

The next field, <replaceable>skipped</replaceable>,

is only meaningful if the <option>--latency-limit</option> option is used, too. Otherwise it is 0.

It counts the number of transactions skipped because they would have

started too late.

</para>

<para>

The <replaceable>retried</replaceable>

and <replaceable>retries</replaceable> fields are only meaningful if

the <option>--max-tries</option> option is not equal to 1. Otherwise they

are 0. They report the number of retried transactions and the sum of all

retries after serialization or deadlock errors within the interval. Each

transaction is counted in the interval when it was committed.

</para>

<para>

<replaceable>failures</replaceable> is the sum of all failed transactions.

If <option>--failures-detailed</option> is specified, instead of the sum of

all failed transactions you will get more detailed statistics for the

failed transactions grouped by the following types:

<replaceable>serialization_failures</replaceable> is the number of

transactions that got a serialization error and were not retried after this,

<replaceable>deadlock_failures</replaceable> is the number of transactions

that got a deadlock error and were not retried after this.

If <option>--failures-detailed</option> is not

specified, <replaceable>serialization_failures</replaceable>

and <replaceable>deadlock_failures</replaceable> are always 0.

Here is some example output with following options:

<userinput>pgbench --aggregate-interval=10 --time=20 --client=10 --log --rate=1000

--latency-limit=10 --failures-detailed --max-tries=10 test</userinput>

Notice that while the plain (unaggregated) log file shows which script

was used for each transaction, the aggregated log does not. Therefore if