Re: Error on pgbench logs
От | Yugo NAGATA |
---|---|
Тема | Re: Error on pgbench logs |
Дата | |
Msg-id | 20210615171514.0f38cb80548fb2fe3fbe20a7@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Error on pgbench logs (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Error on pgbench logs
|
Список | 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 по дате отправления: