public inbox for [email protected]
help / color / mirror / Atom feedpgbench --continue-on-error: clarify TPS and failure reporting
6+ messages / 3 participants
[nested] [flat]
* pgbench --continue-on-error: clarify TPS and failure reporting
@ 2026-06-18 03:24 Chao Li <[email protected]>
2026-06-18 05:36 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Yugo Nagata <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Chao Li @ 2026-06-18 03:24 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Fujii Masao <[email protected]>; Rintaro Ikeda <[email protected]>; Yugo Nagata <[email protected]>
Hi
While testing “[0ab208fa5] pgbench: Add --continue-on-error option”, I got a question about the doc:
```
<para>
This option is useful when your custom script may raise errors
such as unique constraint violations, but you want the benchmark
to continue and measure performance including those failures.
</para>
```
The phrase “measure performance including those failures” gives the impression that failed transactions might be counted in TPS, but they are not.
In my test, all transactions failed, and TPS was reported as 0:
```
% pgbench -d evantest -n -t 5 --continue-on-error --failures-detailed -f pgbench-coe.sql
pgbench (19beta1)
transaction type: pgbench-coe.sql
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
maximum number of tries: 1
number of transactions per client: 5
number of transactions actually processed: 0/5
number of failed transactions: 5 (100.000%)
number of serialization failures: 0 (0.000%)
number of deadlock failures: 0 (0.000%)
number of other failures: 5 (100.000%)
latency average = 0.389 ms (including failures)
initial connection time = 4.172 ms
tps = 0.000000 (without initial connection time)
```
If this behavior is intended, I wonder if we should clarify the TPS counting logic more explicitly. For example:
```
<para>
This option is useful when your custom script may raise errors
such as unique constraint violations, but you want the benchmark
to continue despite individual statement failures. Failed transactions
are reported separately and included in latency statistics, but are not
counted as transactions actually processed for TPS.
</para>
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgbench --continue-on-error: clarify TPS and failure reporting
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
@ 2026-06-18 05:36 ` Yugo Nagata <[email protected]>
2026-06-18 06:25 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Yugo Nagata @ 2026-06-18 05:36 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: pgsql-hackers; Fujii Masao <[email protected]>; Rintaro Ikeda <[email protected]>
On Thu, 18 Jun 2026 11:24:04 +0800
Chao Li <[email protected]> wrote:
> Hi
>
> While testing “[0ab208fa5] pgbench: Add --continue-on-error option”, I got a question about the doc:
> ```
> <para>
> This option is useful when your custom script may raise errors
> such as unique constraint violations, but you want the benchmark
> to continue and measure performance including those failures.
> </para>
> ```
>
> The phrase “measure performance including those failures” gives the impression that failed transactions might be counted in TPS, but they are not.
I agree with your point. The original phrasing "including those failures" is
indeed ambiguous and could mislead users into thinking failed transactions are
included in the TPS calculation.
> In my test, all transactions failed, and TPS was reported as 0:
> ```
> % pgbench -d evantest -n -t 5 --continue-on-error --failures-detailed -f pgbench-coe.sql
> pgbench (19beta1)
> transaction type: pgbench-coe.sql
> scaling factor: 1
> query mode: simple
> number of clients: 1
> number of threads: 1
> maximum number of tries: 1
> number of transactions per client: 5
> number of transactions actually processed: 0/5
> number of failed transactions: 5 (100.000%)
> number of serialization failures: 0 (0.000%)
> number of deadlock failures: 0 (0.000%)
> number of other failures: 5 (100.000%)
> latency average = 0.389 ms (including failures)
> initial connection time = 4.172 ms
> tps = 0.000000 (without initial connection time)
> ```
>
> If this behavior is intended, I wonder if we should clarify the TPS counting logic more explicitly. For example:
> ```
> <para>
> This option is useful when your custom script may raise errors
> such as unique constraint violations, but you want the benchmark
> to continue despite individual statement failures. Failed transactions
> are reported separately and included in latency statistics, but are not
> counted as transactions actually processed for TPS.
> </para>
> ```
Your proposed documentation change is much clearer and accurately reflects
the actual behavior. I prefer this version as well.
Regards,
Yugo Nagata
--
Yugo Nagata <[email protected]>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgbench --continue-on-error: clarify TPS and failure reporting
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 05:36 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Yugo Nagata <[email protected]>
@ 2026-06-18 06:25 ` Chao Li <[email protected]>
2026-06-18 09:40 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Fujii Masao <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Chao Li @ 2026-06-18 06:25 UTC (permalink / raw)
To: Yugo Nagata <[email protected]>; +Cc: pgsql-hackers; Fujii Masao <[email protected]>; Rintaro Ikeda <[email protected]>
> On Jun 18, 2026, at 13:36, Yugo Nagata <[email protected]> wrote:
>
> On Thu, 18 Jun 2026 11:24:04 +0800
> Chao Li <[email protected]> wrote:
>
>> Hi
>>
>> While testing “[0ab208fa5] pgbench: Add --continue-on-error option”, I got a question about the doc:
>> ```
>> <para>
>> This option is useful when your custom script may raise errors
>> such as unique constraint violations, but you want the benchmark
>> to continue and measure performance including those failures.
>> </para>
>> ```
>>
>> The phrase “measure performance including those failures” gives the impression that failed transactions might be counted in TPS, but they are not.
>
> I agree with your point. The original phrasing "including those failures" is
> indeed ambiguous and could mislead users into thinking failed transactions are
> included in the TPS calculation.
>
>> In my test, all transactions failed, and TPS was reported as 0:
>> ```
>> % pgbench -d evantest -n -t 5 --continue-on-error --failures-detailed -f pgbench-coe.sql
>> pgbench (19beta1)
>> transaction type: pgbench-coe.sql
>> scaling factor: 1
>> query mode: simple
>> number of clients: 1
>> number of threads: 1
>> maximum number of tries: 1
>> number of transactions per client: 5
>> number of transactions actually processed: 0/5
>> number of failed transactions: 5 (100.000%)
>> number of serialization failures: 0 (0.000%)
>> number of deadlock failures: 0 (0.000%)
>> number of other failures: 5 (100.000%)
>> latency average = 0.389 ms (including failures)
>> initial connection time = 4.172 ms
>> tps = 0.000000 (without initial connection time)
>> ```
>>
>> If this behavior is intended, I wonder if we should clarify the TPS counting logic more explicitly. For example:
>> ```
>> <para>
>> This option is useful when your custom script may raise errors
>> such as unique constraint violations, but you want the benchmark
>> to continue despite individual statement failures. Failed transactions
>> are reported separately and included in latency statistics, but are not
>> counted as transactions actually processed for TPS.
>> </para>
>> ```
>
> Your proposed documentation change is much clearer and accurately reflects
> the actual behavior. I prefer this version as well.
>
> Regards,
> Yugo Nagata
>
> --
> Yugo Nagata <[email protected]>
Thanks for confirming the doc issue. The here comes a small doc patch.
I also noticed there is a later paragraph about “latency” that also needs an update, it’s included in the patch as well.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
[application/octet-stream] v1-0001-doc-Clarify-pgbench-reporting-with-continue-on-er.patch (2.3K, ../../[email protected]/2-v1-0001-doc-Clarify-pgbench-reporting-with-continue-on-er.patch)
download | inline diff:
From abf245787746ffa7f696298d22101b4e0226f711 Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <[email protected]>
Date: Thu, 18 Jun 2026 14:21:13 +0800
Subject: [PATCH v1] doc: Clarify pgbench reporting with --continue-on-error
Clarify that transactions failed under --continue-on-error are reported
separately and are not counted as transactions actually processed or in
TPS. Also adjust the latency description to avoid implying that failed
transactions are generally included in latency measurements.
Author: Chao Li <[email protected]>
Reviewed-by: Yugo Nagata <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
doc/src/sgml/ref/pgbench.sgml | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 2e401d1ceb8..abdb1df6c89 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -770,10 +770,13 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
the connection to fail.
See <xref linkend="failures-and-retries"/> for more information.
</para>
+
<para>
This option is useful when your custom script may raise errors
such as unique constraint violations, but you want the benchmark
- to continue and measure performance including those failures.
+ to continue despite individual statement failures. Failed
+ transactions are reported separately, but are not counted as
+ transactions actually processed, nor are they included in TPS.
</para>
</listitem>
</varlistentry>
@@ -2933,9 +2936,10 @@ statement latencies in milliseconds, failures and retries:
<para>
The latency of a successful transaction includes the entire time of
- transaction execution with rollbacks and retries. The latency is measured
- only for successful transactions and commands but not for failed transactions
- or commands.
+ transaction execution with rollbacks and retries. The latency is measured
+ only for successful transactions and commands, except that failed
+ transactions are included in the simple average latency when the
+ <option>--continue-on-error</option> option is used.
</para>
<para>
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgbench --continue-on-error: clarify TPS and failure reporting
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 05:36 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Yugo Nagata <[email protected]>
2026-06-18 06:25 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
@ 2026-06-18 09:40 ` Fujii Masao <[email protected]>
2026-06-18 12:45 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2026-06-18 09:40 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: Yugo Nagata <[email protected]>; pgsql-hackers; Rintaro Ikeda <[email protected]>
On Thu, Jun 18, 2026 at 3:25 PM Chao Li <[email protected]> wrote:
> Thanks for confirming the doc issue. The here comes a small doc patch.
>
> I also noticed there is a later paragraph about “latency” that also needs an update, it’s included in the patch as well.
Thanks for the patch! The TPS-related changes look good to me.
The latency of a successful transaction includes the entire time of
- transaction execution with rollbacks and retries. The latency is measured
- only for successful transactions and commands but not for failed
transactions
- or commands.
+ transaction execution with rollbacks and retries. The latency is measured
+ only for successful transactions and commands, except that failed
+ transactions are included in the simple average latency when the
+ <option>--continue-on-error</option> option is used.
It doesn't seem that the behavior of the latency average in the main
report depends on --continue-on-error itself. Instead, when neither
--progress, --rate, nor --latency-limit is specified, the main
report shows a simple latency average computed as the total benchmark
duration divided by the number of successful and failed transactions,
so failed transactions are included.
On the other hand, when any of those options is specified, the
latency average and latency stddev in the main report are based
only on successful transactions. Likewise, the per-script and
per-command latency statistics are measured only for successful
transactions and commands.
So how about something like this instead?
-------------------------------
<para>
The latency of a successful transaction includes the entire time of
- transaction execution with rollbacks and retries. The simple
- <literal>latency average</literal> shown in the main report is computed from
- the total benchmark duration divided by both successful and failed
- transactions, and therefore includes failed transactions. In contrast,
- detailed latency statistics, including the per-script and per-command
- reports, are measured only for successful transactions and commands, not
- for failed transactions or commands.
+ transaction execution with rollbacks and retries. In the main report, when
+ neither <option>--progress</option>, <option>--rate</option>, nor
+ <option>--latency-limit</option> is specified, the
+ <literal>latency average</literal> is computed from the total benchmark
+ duration divided by both successful and failed transactions, and therefore
+ includes failed transactions. Otherwise, the <literal>latency
average</literal>
+ and <literal>latency stddev</literal> shown in the main report are measured
+ only for successful transactions. Detailed latency statistics, including
+ the per-script and per-command reports, are also measured only for
+ successful transactions and commands, not for failed transactions or
+ commands.
</para>
-------------------------------
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgbench --continue-on-error: clarify TPS and failure reporting
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 05:36 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Yugo Nagata <[email protected]>
2026-06-18 06:25 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 09:40 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Fujii Masao <[email protected]>
@ 2026-06-18 12:45 ` Chao Li <[email protected]>
2026-06-22 08:10 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Chao Li @ 2026-06-18 12:45 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Yugo Nagata <[email protected]>; pgsql-hackers; Rintaro Ikeda <[email protected]>
> On Jun 18, 2026, at 17:40, Fujii Masao <[email protected]> wrote:
>
> On Thu, Jun 18, 2026 at 3:25 PM Chao Li <[email protected]> wrote:
>> Thanks for confirming the doc issue. The here comes a small doc patch.
>>
>> I also noticed there is a later paragraph about “latency” that also needs an update, it’s included in the patch as well.
>
> Thanks for the patch! The TPS-related changes look good to me.
>
> The latency of a successful transaction includes the entire time of
> - transaction execution with rollbacks and retries. The latency is measured
> - only for successful transactions and commands but not for failed
> transactions
> - or commands.
> + transaction execution with rollbacks and retries. The latency is measured
> + only for successful transactions and commands, except that failed
> + transactions are included in the simple average latency when the
> + <option>--continue-on-error</option> option is used.
>
> It doesn't seem that the behavior of the latency average in the main
> report depends on --continue-on-error itself. Instead, when neither
> --progress, --rate, nor --latency-limit is specified, the main
> report shows a simple latency average computed as the total benchmark
> duration divided by the number of successful and failed transactions,
> so failed transactions are included.
>
> On the other hand, when any of those options is specified, the
> latency average and latency stddev in the main report are based
> only on successful transactions. Likewise, the per-script and
> per-command latency statistics are measured only for successful
> transactions and commands.
>
> So how about something like this instead?
>
> -------------------------------
> <para>
> The latency of a successful transaction includes the entire time of
> - transaction execution with rollbacks and retries. The simple
> - <literal>latency average</literal> shown in the main report is computed from
> - the total benchmark duration divided by both successful and failed
> - transactions, and therefore includes failed transactions. In contrast,
> - detailed latency statistics, including the per-script and per-command
> - reports, are measured only for successful transactions and commands, not
> - for failed transactions or commands.
> + transaction execution with rollbacks and retries. In the main report, when
> + neither <option>--progress</option>, <option>--rate</option>, nor
> + <option>--latency-limit</option> is specified, the
> + <literal>latency average</literal> is computed from the total benchmark
> + duration divided by both successful and failed transactions, and therefore
> + includes failed transactions. Otherwise, the <literal>latency
> average</literal>
> + and <literal>latency stddev</literal> shown in the main report are measured
> + only for successful transactions. Detailed latency statistics, including
> + the per-script and per-command reports, are also measured only for
> + successful transactions and commands, not for failed transactions or
> + commands.
> </para>
> -------------------------------
>
I feel that might be too detailed. Listing these three option names here could make the doc harder to read and maintain. When failures are included, the output line already says so explicitly:
```
latency average = 0.387 ms (including failures)
```
Can we simply say something like this?
```
<para>
The latency of a successful transaction includes the entire time of
transaction execution with rollbacks and retries. The latency is measured
only for successful transactions and commands, not for failed transactions
or commands, unless the report explicitly says that it includes failures.
</para>
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pgbench --continue-on-error: clarify TPS and failure reporting
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 05:36 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Yugo Nagata <[email protected]>
2026-06-18 06:25 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 09:40 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Fujii Masao <[email protected]>
2026-06-18 12:45 ` Re: pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
@ 2026-06-22 08:10 ` Chao Li <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Chao Li @ 2026-06-22 08:10 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Yugo Nagata <[email protected]>; pgsql-hackers; Rintaro Ikeda <[email protected]>
> On Jun 18, 2026, at 20:45, Chao Li <[email protected]> wrote:
>
>
>
>> On Jun 18, 2026, at 17:40, Fujii Masao <[email protected]> wrote:
>>
>> On Thu, Jun 18, 2026 at 3:25 PM Chao Li <[email protected]> wrote:
>>> Thanks for confirming the doc issue. The here comes a small doc patch.
>>>
>>> I also noticed there is a later paragraph about “latency” that also needs an update, it’s included in the patch as well.
>>
>> Thanks for the patch! The TPS-related changes look good to me.
>>
>> The latency of a successful transaction includes the entire time of
>> - transaction execution with rollbacks and retries. The latency is measured
>> - only for successful transactions and commands but not for failed
>> transactions
>> - or commands.
>> + transaction execution with rollbacks and retries. The latency is measured
>> + only for successful transactions and commands, except that failed
>> + transactions are included in the simple average latency when the
>> + <option>--continue-on-error</option> option is used.
>>
>> It doesn't seem that the behavior of the latency average in the main
>> report depends on --continue-on-error itself. Instead, when neither
>> --progress, --rate, nor --latency-limit is specified, the main
>> report shows a simple latency average computed as the total benchmark
>> duration divided by the number of successful and failed transactions,
>> so failed transactions are included.
>>
>> On the other hand, when any of those options is specified, the
>> latency average and latency stddev in the main report are based
>> only on successful transactions. Likewise, the per-script and
>> per-command latency statistics are measured only for successful
>> transactions and commands.
>>
>> So how about something like this instead?
>>
>> -------------------------------
>> <para>
>> The latency of a successful transaction includes the entire time of
>> - transaction execution with rollbacks and retries. The simple
>> - <literal>latency average</literal> shown in the main report is computed from
>> - the total benchmark duration divided by both successful and failed
>> - transactions, and therefore includes failed transactions. In contrast,
>> - detailed latency statistics, including the per-script and per-command
>> - reports, are measured only for successful transactions and commands, not
>> - for failed transactions or commands.
>> + transaction execution with rollbacks and retries. In the main report, when
>> + neither <option>--progress</option>, <option>--rate</option>, nor
>> + <option>--latency-limit</option> is specified, the
>> + <literal>latency average</literal> is computed from the total benchmark
>> + duration divided by both successful and failed transactions, and therefore
>> + includes failed transactions. Otherwise, the <literal>latency
>> average</literal>
>> + and <literal>latency stddev</literal> shown in the main report are measured
>> + only for successful transactions. Detailed latency statistics, including
>> + the per-script and per-command reports, are also measured only for
>> + successful transactions and commands, not for failed transactions or
>> + commands.
>> </para>
>> -------------------------------
>>
>
> I feel that might be too detailed. Listing these three option names here could make the doc harder to read and maintain. When failures are included, the output line already says so explicitly:
> ```
> latency average = 0.387 ms (including failures)
> ```
>
> Can we simply say something like this?
> ```
> <para>
> The latency of a successful transaction includes the entire time of
> transaction execution with rollbacks and retries. The latency is measured
> only for successful transactions and commands, not for failed transactions
> or commands, unless the report explicitly says that it includes failures.
> </para>
> ```
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
Thinking it over, I came up with a version that combines Fujii-san’s suggestion and my previous version:
```
<para>
The latency of a successful transaction includes the entire time of
transaction execution with rollbacks and retries. In the main report,
when none of <option>--progress</option>, <option>--rate</option>, and
<option>--latency-limit</option> is specified, <literal>latency average</literal>
is computed from both successful and failed transactions. In such cases,
this is explicitly indicated by <literal>(including failures)</literal>.
Other latency statistics, including the per-script and per-command reports,
are measured only for successful transactions and commands, not for failed
transactions or commands.
</para>
```
PFA v2.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
[application/octet-stream] v2-0001-doc-Clarify-pgbench-reporting-with-continue-on-er.patch (2.6K, ../../[email protected]/2-v2-0001-doc-Clarify-pgbench-reporting-with-continue-on-er.patch)
download | inline diff:
From 0a944fb519d8eeb74037dccbf3cf5f40ce613180 Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <[email protected]>
Date: Thu, 18 Jun 2026 14:21:13 +0800
Subject: [PATCH v2] doc: Clarify pgbench reporting with --continue-on-error
Clarify that transactions failed under --continue-on-error are reported
separately and are not counted as transactions actually processed or in
TPS. Also adjust the latency description to avoid implying that failed
transactions are generally included in latency measurements.
Author: Chao Li <[email protected]>
Reviewed-by: Yugo Nagata <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
doc/src/sgml/ref/pgbench.sgml | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 2e401d1ceb8..7619b8ad743 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -770,10 +770,13 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>d
the connection to fail.
See <xref linkend="failures-and-retries"/> for more information.
</para>
+
<para>
This option is useful when your custom script may raise errors
such as unique constraint violations, but you want the benchmark
- to continue and measure performance including those failures.
+ to continue despite individual statement failures. Failed
+ transactions are reported separately, but are not counted as
+ transactions actually processed, nor are they included in TPS.
</para>
</listitem>
</varlistentry>
@@ -2933,9 +2936,14 @@ statement latencies in milliseconds, failures and retries:
<para>
The latency of a successful transaction includes the entire time of
- transaction execution with rollbacks and retries. The latency is measured
- only for successful transactions and commands but not for failed transactions
- or commands.
+ transaction execution with rollbacks and retries. In the main report,
+ when none of <option>--progress</option>, <option>--rate</option>, and
+ <option>--latency-limit</option> is specified, <literal>latency average</literal>
+ is computed from both successful and failed transactions. In such cases,
+ this is explicitly indicated by <literal>(including failures)</literal>.
+ Other latency statistics, including the per-script and per-command reports,
+ are measured only for successful transactions and commands, not for failed
+ transactions or commands.
</para>
<para>
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-06-22 08:10 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-18 03:24 pgbench --continue-on-error: clarify TPS and failure reporting Chao Li <[email protected]>
2026-06-18 05:36 ` Yugo Nagata <[email protected]>
2026-06-18 06:25 ` Chao Li <[email protected]>
2026-06-18 09:40 ` Fujii Masao <[email protected]>
2026-06-18 12:45 ` Chao Li <[email protected]>
2026-06-22 08:10 ` Chao Li <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox