On Mon, 12 Feb 2007, NikhilS wrote:
From your patch I see that it augments the -l flag. IMHO it does not
make sense to add another flag. We can save the "if" check and log the
extended contents as part of -l itself.
I wanted something people could apply to 8.2 without breaking existing
scrip
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
Hello, Greg-san
> The attached adds two new command line switches to pgbench:
If you are OK, could you make the measurement of time on Windows more
precise? The Win32 APIs that pgbench is using for gettimeofday() (in
src/port/gettimeofday.c) is much lower in resolution than Linux. The
Win32 API
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 e
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ultimately, the result was that glibc was wrong in its locale settings,
> > and there was a suggestion to use defaults only when using the C locale.
> > However, I am worried there are too many locales in the field that only
> > define
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 whole latency
side of pgbench pretty useless on Win32. There is
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. On
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