Ok, I added a reference to the commitfest entry from this wiki page, and a
note about partial 9.5 backporting.
Please split the patch into one part for backporting and one part for
master-only and post both patches, clearly indicating which is which.
Attached are the full patch for head and the backport part (the patch name
ends with "backport") separated.
--
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>
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index c6d1454..e82db70 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1112,10 +1112,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>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
