From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, rulyox(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Error on pgbench logs |
Date: | 2021-06-15 08:05:29 |
Message-ID: | alpine.DEB.2.22.394.2106150828380.1864934@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Michaël,
>> I think we don't have to call doLog() before logAgg(). If we call doLog(),
>> we will count an extra transaction that is not actually processed because
>> accumStats() is called in this.
>
> Yes, calling both is weird.
The motivation to call doLog is to catch up zeros on slow rates, so as to
avoid holes in the log, including at the end of the run. This "trick" was
already used by the code. I agree that it would record a non existant
transaction, which is not desirable. I wanted to avoid a special
parameter, but this seems unrealistic.
> Is using logAgg() directly in the context actually right when it comes
> to sample_rate?
The point is just to trigger the last display, which is not triggered by
the previous I think because of the precision: the start of the run is
not exactly the start of the thread.
> We may not log anything on HEAD if sample_rate is enabled, but we would
> finish by logging something all the time with this patch.
I do not get it.
> If I am following this code correctly, we don't care about accumStats()
> in the code path of a thread we are done with, right?
Yes.
Attached a v3 which adds a boolean to distinguish recording vs flushing.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2021-06-15 08:15:14 | Re: Error on pgbench logs |
Previous Message | Laurenz Albe | 2021-06-15 07:37:11 | Re: Use singular number when appropriate |