From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench: option delaying queries till connections establishment? |
Date: | 2020-05-17 09:55:43 |
Message-ID: | alpine.DEB.2.22.394.2005171141510.977310@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
Attachment | Content-Type | Size |
---|---|---|
pgbench-usec-1.patch | text/x-diff | 33.5 KB |
pgbench-barrier-4.patch | text/x-diff | 3.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-05-17 15:28:51 | Re: Add A Glossary |
Previous Message | Alexander Korotkov | 2020-05-17 09:47:27 | Re: pgsql: Show opclass and opfamily related information in psql |