Hello Tomas,
while learning about format of the transaction log produced by pgbench, I've
noticed this sentence in the section describing format of the per-transaction
log:
The last field skipped_transactions reports the number of
transactions skipped because they were too far behind schedule.
It is only present when both options --rate and --latency-limit
are used.
Which is wrong, because this field is only added in the aggregated log, not
in the per-transaction one. So we should delete this.
Indeed.
Several builtin scripts can be specified with -b as well, and -b and -f
can be mixed, the file_no should be renamed script_no and refer to both -b
and -f.
It also does not explicitly explain that with --latency-limit the latency
column will contain "skipped" for transactions exceeding the limit latency
(it's only mentioned in the example output).
Ok.
So I think we should apply the attached patch (and also backpatch it to 9.5,
where the --latency-limit got introduced).
Here is an updated version of your proposal:
- use <literal> instead of "
- use script_no and mention -b as well
- spell out skipped explanation after the sample output
Also, while reading the doc, I really think that the timestamp should be
made explicit milliseconds, i.e. "123.004567" instead of "123 4567", but
that is another question not relevant to this patch.
--
Fabien.
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index cc80b3f..1a4c1f4 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1075,12 +1075,12 @@ END;
The format of the log is:
<synopsis>
-<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</> <optional><replaceable>schedule_lag</replaceable></optional>
+<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>script_no</> <replaceable>time_epoch</> <replaceable>time_us</> <optional><replaceable>schedule_lag</replaceable></optional>
</synopsis>
where <replaceable>time</> is the total elapsed transaction time in microseconds,
- <replaceable>file_no</> identifies which script file was used
- (useful when multiple scripts were specified with <option>-f</>),
+ <replaceable>script_no</> identifies which script file was used (useful when
+ multiple scripts were specified with <option>-f</> or <option>-b</>),
and <replaceable>time_epoch</>/<replaceable>time_us</> are a
Unix epoch format time stamp and an offset
in microseconds (suitable for creating an ISO 8601
@@ -1089,10 +1089,8 @@ END;
Field <replaceable>schedule_lag</> 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 is used.
- The last field <replaceable>skipped_transactions</> reports the number of
- transactions skipped because they were too far behind schedule. It is only
- present when both options <option>--rate</> and <option>--latency-limit</>
- are used.
+ When both options <option>--rate</> and <option>--latency-limit</> are used,
+ the skipped transactions will use <literal>skipped</> in place of latency.
</para>
<para>
@@ -1117,7 +1115,8 @@ END;
</screen>
In this example, transaction 82 was late, because it's latency (6.173 ms) was
over the 5 ms limit. The next two transactions were skipped, because they
- were already late before they were even started.
+ were already late before they were even started (5217 and 5099
+ microsecond schedule lags on the last column are above the 5 ms limit).
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
