Re: pgbench: option delaying queries till connectionsestablishment?
От | Fabien COELHO |
---|---|
Тема | Re: pgbench: option delaying queries till connectionsestablishment? |
Дата | |
Msg-id | alpine.DEB.2.21.2002291531360.25187@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench: option delaying queries till connectionsestablishment? (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
Hello Kyotaro-san, >> I think this also shows that "including/excluding connections >> establishing" as well as some of the other stats reported pretty >> bogus. In the 'before' case a substantial numer of the connections had >> not yet been established until the end of the test run! > > I see it useful. In most cases we don't care connection time of > pgbench. Especially in the mentioned case the result is just bogus. I > think the reason for "including/excluding connection establishing" is > not that people wants to see how long connection took to establish but > that how long the substantial work took. If each client did run with > continuously re-establishing new connections the connection time would > be useful, but actually all the connections are established at once at > the beginning. > > So FWIW I prefer that the barrier is applied by default Yep. > (that is, it can be disabled) On reflection, I'm not sure I see a use case for not running the barrier if it is available. > and the progress time starts at the time all clients has been > established. Yep, the start time should be set after the connection barrier, and possibly before a start barrier to ensure that no transaction has started before the start time: although performance measures are expected to be slightly false because of how they are measured (measuring takes time), from a benchmarking perspective the displayed result should be <= the actual performance. Now, again, if long benchmarks are run, which for a db should more or less always be the case, this should not matter much. >> starting vacuum...end. > + time to established 5000 connections: 1323ms Yep, maybe showing the initial connection time separately. -- Fabien.
В списке pgsql-hackers по дате отправления: