On Wed, 1 Sep 2021 17:07:43 +0900
Fujii Masao wrote:
>
>
> On 2021/09/01 1:10, Fujii Masao wrote:
> > +1. So we reached the consensus!
> >
> > Attached is the updated version of the patch. Based on Nagata-san's latest
> > patch,
> > I just modified the comment slightly and ran pgindent. Barri
On 2021/09/01 1:10, Fujii Masao wrote:
+1. So we reached the consensus!
Attached is the updated version of the patch. Based on Nagata-san's latest
patch,
I just modified the comment slightly and ran pgindent. Barring any objection,
I will commit this patch only in master and v14.
Pushed. T
On 2021/08/31 16:56, Fabien COELHO wrote:
I would think we should leave as it is for pg13 and before to not surprise
users.
Ok. Thank you for your opinion. I also agree with not changing the behavior of
long-stable branches, and I think this is the same opinion as Fujii-san.
Attached is t
I would think we should leave as it is for pg13 and before to not surprise
users.
Ok. Thank you for your opinion. I also agree with not changing the behavior of
long-stable branches, and I think this is the same opinion as Fujii-san.
Attached is the patch to fix to measure disconnection del
On Tue, 31 Aug 2021 15:39:18 +0900 (JST)
Tatsuo Ishii wrote:
> >> >> > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to
> >> >> > include disconnection times, which are clearly linked to connections,
> >> >> > especially with -C. So I'd rather have the more meaningful figure
>> >> > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to
>> >> > include disconnection times, which are clearly linked to connections,
>> >> > especially with -C. So I'd rather have the more meaningful figure even
>> >> > at the price of a small change in an undocumented featu
On Tue, 31 Aug 2021 14:46:42 +0900 (JST)
Tatsuo Ishii wrote:
> >> > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to
> >> > include disconnection times, which are clearly linked to connections,
> >> > especially with -C. So I'd rather have the more meaningful figure even
> >
>> > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to
>> > include disconnection times, which are clearly linked to connections,
>> > especially with -C. So I'd rather have the more meaningful figure even
>> > at the price of a small change in an undocumented feature.
>>
>> +
Hello Fabien, Ishii-san,
On Tue, 31 Aug 2021 14:18:48 +0900 (JST)
Tatsuo Ishii wrote:
> >>> Ok. That makes sense. The output reports "including connections
> >>> establishing" and "excluding connections establishing" regardless with
> >>> -C, so we should measure delays in the same way.
> >>
> >
>>> Ok. That makes sense. The output reports "including connections
>>> establishing" and "excluding connections establishing" regardless with
>>> -C, so we should measure delays in the same way.
>>
>> On second thought, it's more reasonable and less confusing not to
>> measure the disconnection de
Hello Fujii-san,
On Mon, 30 Aug 2021 23:36:30 +0900
Fujii Masao wrote:
>
>
> On 2021/08/26 12:13, Yugo NAGATA wrote:
> > Ok. That makes sense. The output reports "including connections
> > establishing"
> > and "excluding connections establishing" regardless with -C, so we should
> > measure
Ok. That makes sense. The output reports "including connections
establishing" and "excluding connections establishing" regardless with
-C, so we should measure delays in the same way.
On second thought, it's more reasonable and less confusing not to
measure the disconnection delays at all? Si
On 2021/08/26 12:13, Yugo NAGATA wrote:
Ok. That makes sense. The output reports "including connections establishing"
and "excluding connections establishing" regardless with -C, so we should
measure delays in the same way.
On second thought, it's more reasonable and less confusing not to
me
> On Mon, 30 Aug 2021 14:22:49 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> >> Anyway, I changed the status of this patch to "Waiting on Author" in CF.
>> >
>> > I returned the status to "Ready for Committer".
>> > Could you please review this?
>>
>> According to the patch tester, the patch does not
On Mon, 30 Aug 2021 14:22:49 +0900 (JST)
Tatsuo Ishii wrote:
> >> Anyway, I changed the status of this patch to "Waiting on Author" in CF.
> >
> > I returned the status to "Ready for Committer".
> > Could you please review this?
>
> According to the patch tester, the patch does not apply.
Wel
>> Anyway, I changed the status of this patch to "Waiting on Author" in CF.
>
> I returned the status to "Ready for Committer".
> Could you please review this?
According to the patch tester, the patch does not apply.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.p
On Fri, 20 Aug 2021 02:05:27 +0900
Fujii Masao wrote:
>
> On 2021/08/11 13:56, Fujii Masao wrote:
> > Yes, but I was thinking that's a bug that we should fix.
> > IOW, I was thinking that, in v13, both connection and disconnection delays
> > should be measured whether -C is specified or not, *pe
On 2021/08/11 13:56, Fujii Masao wrote:
Yes, but I was thinking that's a bug that we should fix.
IOW, I was thinking that, in v13, both connection and disconnection delays
should be measured whether -C is specified or not, *per spec*.
But, in v13, the disconnection delays are not measured in t
On 2021/08/05 18:02, Yugo NAGATA wrote:
this is a no-op because finishCon() is already called at CSTATE_ABORTED or
CSTATE_FINISHED. Therefore, in the end, the disconnection delay is not
measured even in v13.
Yes, but I was thinking that's a bug that we should fix.
IOW, I was thinking that, i
Hello Fujii-san,
On Thu, 5 Aug 2021 16:16:48 +0900
Fujii Masao wrote:
>
>
> On 2021/08/01 14:50, Yugo NAGATA wrote:
> > When -C is not specified, the disconnection time is not measured even in
> > the patch for v14+. I don't think it is a problem because the
> > disconnection delay at the end
On 2021/08/01 14:50, Yugo NAGATA wrote:
When -C is not specified, the disconnection time is not measured even in
the patch for v14+. I don't think it is a problem because the
disconnection delay at the end of benchmark almost doesn't affect the tps.
What about v13 or before? That is, in v13,
On Fri, 30 Jul 2021 15:26:51 +0900
Fujii Masao wrote:
>
>
> On 2021/07/30 14:43, Yugo NAGATA wrote:
> > This patch fixes three issues of connection time measurement:
> >
> > 1. The initial connection time is measured and stored into conn_duration
> > but the result is never used.
> > 2. Th
On 2021/07/30 14:43, Yugo NAGATA wrote:
This patch fixes three issues of connection time measurement:
1. The initial connection time is measured and stored into conn_duration
but the result is never used.
2. The disconnection time are not measured even when -C is specified.
3. The disconn
Hello Fujii-san,
On Fri, 30 Jul 2021 02:01:08 +0900
Fujii Masao wrote:
>
>
> On 2021/07/29 2:23, Fujii Masao wrote:
> >
> >
> > On 2021/07/28 16:15, Yugo NAGATA wrote:
> >>> I found another disconnect_all().
> >>>
> >>> /* XXX should this be connection time? */
> >>> disconnect_all(s
On 2021/07/29 2:23, Fujii Masao wrote:
On 2021/07/28 16:15, Yugo NAGATA wrote:
I found another disconnect_all().
/* XXX should this be connection time? */
disconnect_all(state, nclients);
The measurement is also not necessary here.
So the above comment should be removed or updated
On 2021/07/28 16:15, Yugo NAGATA wrote:
I found another disconnect_all().
/* XXX should this be connection time? */
disconnect_all(state, nclients);
The measurement is also not necessary here.
So the above comment should be removed or updated?
I think this disconnect_all wi
Hello Fujii-san,
On Wed, 28 Jul 2021 00:20:21 +0900
Fujii Masao wrote:
>
>
> On 2021/07/27 11:02, Yugo NAGATA wrote:
> > Hello Fujii-san,
> >
> > Thank you for looking at it.
> >
> > On Tue, 27 Jul 2021 03:04:35 +0900
> > Fujii Masao wrote:
> + * Per-thread la
On 2021/07/27 11:02, Yugo NAGATA wrote:
Hello Fujii-san,
Thank you for looking at it.
On Tue, 27 Jul 2021 03:04:35 +0900
Fujii Masao wrote:
case CSTATE_FINISHED:
+ /* per-thread last disconnection time is not
measured */
Could you te
Hello Fujii-san,
Thank you for looking at it.
On Tue, 27 Jul 2021 03:04:35 +0900
Fujii Masao wrote:
> case CSTATE_FINISHED:
> + /* per-thread last disconnection time is not
> measured */
>
> Could you tell me why we don't need to do this measu
On 2021/06/30 14:43, Yugo NAGATA wrote:
On Wed, 30 Jun 2021 14:35:37 +0900
Yugo NAGATA wrote:
Hello Asif,
On Tue, 29 Jun 2021 13:21:54 +
Asif Rehman wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements fe
On Wed, 30 Jun 2021 14:35:37 +0900
Yugo NAGATA wrote:
> Hello Asif,
>
> On Tue, 29 Jun 2021 13:21:54 +
> Asif Rehman wrote:
>
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature: tested, pass
Hello Asif,
On Tue, 29 Jun 2021 13:21:54 +
Asif Rehman wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
This patch looks fine to me. master 48cb244fb9
The new status of
On Mon, 14 Jun 2021 10:57:07 +0200 (CEST)
Fabien COELHO wrote:
> > However, I found that conn_duration is calculated even when -C/--connect
> > is not specified, which is waste. SO we can remove this code as fixed in
> > the attached patch.
>
> I'm fine with the implied code simplification, but
Hello Yugo-san,
TState has a field called "conn_duration" and this is, the comment says,
"cumulated connection and deconnection delays". This value is summed over
threads and reported as "average connection time" under -C/--connect.
If this options is not specified, the value is never used.
Y
Hi,
TState has a field called "conn_duration" and this is, the comment says,
"cumulated connection and deconnection delays". This value is summed over
threads and reported as "average connection time" under -C/--connect.
If this options is not specified, the value is never used.
However, I found
36 matches
Mail list logo
