Re: Error on pgbench logs - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: Error on pgbench logs
Date
Msg-id 20210615171514.0f38cb80548fb2fe3fbe20a7@sraoss.co.jp
Whole thread Raw
In response to Re: Error on pgbench logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Error on pgbench logs  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, 15 Jun 2021 10:05:29 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

> 
> 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.

It was not a problem  because --sampling-rate --aggregate-interval cannot be
used at the same time.
 
> > 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.

Sorry, but I can't find any patach attached...

-- 
Yugo NAGATA <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Error on pgbench logs
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Signed vs. Unsigned (some)