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 is
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 mak
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
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
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
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
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
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, 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
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
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> 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
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 t
Neil Conway wrote:
> 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.
To me, it is a clear lin
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 broadcas
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 resul
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 defau
The attached adds two new command line switches to pgbench:
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
-X: Do extra cleanup after the run (vacuum on all tables, checkpoint)
before stopping the clock. This gives substantially more consistancy
17 matches
Mail list logo
