Re: [HACKERS] pgbench tap tests & minor fixes
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench tap tests & minor fixes |
Дата | |
Msg-id | alpine.DEB.2.20.1705082307580.3983@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench tap tests & minor fixes (Nikolay Shaplov <dhyan@nataraj.su>) |
Ответы |
Re: [HACKERS] pgbench tap tests & minor fixes
|
Список | pgsql-hackers |
Hello, > st->cnt -- number of transactions finished successed or failed, right? Or *skipped*. That is why I changed the declaration comment. > one iteration of for(;;) is for one transaction or really less. Right? No, under -R -L late schedules are simply skipped. > We can't process two tansactions in one iteration of this loop. So we > can't increase st->cnt more then once during one iteration? Yes we can, if they are skipped because the scheduling was too late to execute them on time. > processXactStats(thread, st, &now, true, agg); > > Let's imagine that thread->throttle_trigger is now_us - 10 000, > latency_limit is 5 000 and throttle_delay is 100 > > How many times you would call processXactStats in this while loop? Around 100 times to catch up. > And each time it would do st->cnt++ Yep. The "true" argument tells the stats that the transaction was skipped, though. It just counting late transaction that could not be processed. > And this while loop is inside for(;;) in which as I said above we can do > st->cnt++ not more than once. I see no logic here. The logic is that at most one *real* transaction is actually performed in the for, but there may be any number of "skipped" (unexecuted) ones, which is fine. > PS This is a fast reply. May be it will make things clear fast wither for me > or for you. I will carefully answer your full letter tomorrow (I hope nothing > will prevent me from doing it) Today was a holiday in France. Tomorrow is not. -- Fabien.
В списке pgsql-hackers по дате отправления: