On 2/12/2007 11:43 AM, Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
Right now when you run pgbench, the results vary considerably from run to
run even if you completely rebuild the database every time. I've found
that a lot of that variation comes from two things:
This is a real
On Tue, Feb 13, 2007 at 01:08:04AM -0500, Greg Smith wrote:
On Tue, 13 Feb 2007, Takayuki Tsunakawa wrote:
The Win32 APIs that pgbench is using for gettimeofday() (in
src/port/gettimeofday.c) is much lower in resolution than Linux.
I wasn't aware of this issue, and it certainly makes the
Greg Smith [EMAIL PROTECTED] writes:
Right now when you run pgbench, the results vary considerably from run to
run even if you completely rebuild the database every time. I've found
that a lot of that variation comes from two things:
This is a real issue, but I think your proposed patch
On Mon, 12 Feb 2007, Tom Lane wrote:
This is a real issue, but I think your proposed patch does not fix it.
I certainly wouldn't claim that my patch _fixes_ the problem in the
general case; it provides one way to measure it. Currently it's not
obvious to new pgbench users that the problem
Hi,
Right now when you run pgbench, the results vary considerably from run to
run even if you completely rebuild the database every time. I've found
that a lot of that variation comes from two things:
The main purpose of pgbench runs is an apples to apples comparison of 2
source bases. One
NikhilS [EMAIL PROTECTED] writes:
As long as we use the same postgresql.conf, same hardware environment and
exactly same parameter pgbench runs, the difference in the TPS values
observed between the 2 sources should be a good enough indicator as to the
viability of the new code, dont you
On Sun, 2007-02-11 at 20:32 -0500, Greg Smith wrote:
The attached adds two new command line switches to pgbench:
FYI, context diffs are preferred.
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
I wonder if it's worth just making this the
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2007-02-11 at 20:32 -0500, Greg Smith wrote:
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
I wonder if it's worth just making this the default.
Does this have any impact on the reported results (by
On Sun, 2007-02-11 at 23:12 -0500, Tom Lane wrote:
No, it isn't. This is *not* a candidate for back-porting.
Why is that? It seems to me that the potential downside is essentially
zero. This is a developer-oriented benchmark tool, after all.
-Neil
---(end of
On Sun, 11 Feb 2007, Tom Lane wrote:
Does this have any impact on the reported results (by slowing pg_bench
itself)?
I didn't put more code than I had to in the transaction path, to avoid any
slowdown. I didn't convert the timestamp to human readable format or
anything intensive like that
Hi,
On 2/12/07, Greg Smith [EMAIL PROTECTED] wrote:
The attached adds two new command line switches to pgbench:
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
From your patch I see that it augments the -l flag. IMHO it does not make
sense to
11 matches
Mail list logo
