Re: pgbench: option delaying queries till connectionsestablishment?
От | Fabien COELHO |
---|---|
Тема | Re: pgbench: option delaying queries till connectionsestablishment? |
Дата | |
Msg-id | alpine.DEB.2.22.394.2005171141510.977310@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench: option delaying queries till connectionsestablishment? (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgbench: option delaying queries till connections establishment?
|
Список | pgsql-hackers |
Hello, >>> I've merged all time-related stuff (time_t, instr_time, int64) to use a >>> unique type (pg_time_usec_t) and set of functions/macros, which simplifies >>> the code somehow. >> >> Hm. I'm not convinced it's a good idea for pgbench to do its own thing >> here. I really think that the refactoring part is a good thing because cloc and cost is reduced (time arithmetic is an ugly pain with instr_time). I have split the patch. * First patch reworks time measurements in pgbench. It creates a convenient pg_time_usec_t and use it everywhere, getting rid of "instr_time_t". The code is somehow simplified wrt what time are taken and what they mean. Instead of displaying 2 tps at the end, which is basically insane, it shows one tps for --connect, which includes reconnection times, and one tps for the usual one connection at startup which simply ignores the initial connection time. This (mostly) refactoring reduces the cloc. * Second patch adds a barrier before starting the bench It applies on top of the previous one. The initial imbalance due to thread creation times is smoothed. I may add a --start-on option afterwards so that several pgbench (running on distinct hosts) can be synchronized, which would be implemented as a delay inserted by thread 0 before the barrier. The windows implementation is more or less blind, if someone can confirm that it works, it would be nice. -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: