pgbench enhancements

I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.

- predefined variable "tps"
The value of variable tps is taken from the scaling factor
specified by -s option.

- -D option
Variable values can be defined by -D option.

- \set command now allows arithmetic calculations.

enjoy,

BTW, running long benchmark using pgbench on BIG tables easily causes
an integer overflow error in following SQLs:

update accounts set abalance = abalance + :delta where aid = :aid;

update tellers set tbalance = tbalance + :delta where tid = :tid;

update branches set bbalance = bbalance + :delta where bid = :bid;

I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

BTW, running long benchmark using pgbench on BIG tables easily causes
an integer overflow error in following SQLs:

Right.

I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?

No. The problem is that the deltas are invariably positive, which is
not realistic (at least *my* bank balance isn't uniformly increasing :-().
I think the correct fix is just to tweak the range of the randomly
distributed deltas to be plus and minus not always plus.

If you change to bigint then post-change results won't be strictly
comparable to pre-change results because of the difference in execution
costs.

regards, tom lane

Hi,

I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.

- predefined variable "tps"
The value of variable tps is taken from the scaling factor
specified by -s option.

- -D option
Variable values can be defined by -D option.

- \set command now allows arithmetic calculations.

Was there a previous patch posted for this? I don't recall seeing it.

cheers

andrew

Hi,

I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.

- predefined variable "tps"
The value of variable tps is taken from the scaling factor
specified by -s option.

- -D option
Variable values can be defined by -D option.

- \set command now allows arithmetic calculations.

Was there a previous patch posted for this? I don't recall seeing it.

Are you saying that I should have posted patches and called for
discussion? I omit the step because a) pgbench is a contrib program,
b) the changes do not break the backward compatibility.

I always call for discussions for questionable part. (for example,
column type change proposal for pgbench tables).
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Hi,

I have committed contrib/pgbench enhanments contributed by Tomoaki
Sato from SRA OSS, Inc. Japan.

- predefined variable "tps"
The value of variable tps is taken from the scaling factor
specified by -s option.

- -D option
Variable values can be defined by -D option.

- \set command now allows arithmetic calculations.

Was there a previous patch posted for this? I don't recall seeing it.

Are you saying that I should have posted patches and called for
discussion? I omit the step because a) pgbench is a contrib program,
b) the changes do not break the backward compatibility.

I always call for discussions for questionable part. (for example,
column type change proposal for pgbench tables).

It's not a big deal, but I was under the impression that even in these
circumstances a patch should be posted first, especially if it changes
user visible behaviour.

cheers

andrew

Tatsuo Ishii <ishii@sraoss.co.jp> writes:

BTW, running long benchmark using pgbench on BIG tables easily causes
an integer overflow error in following SQLs:

Right.

I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?

No. The problem is that the deltas are invariably positive, which is
not realistic (at least *my* bank balance isn't uniformly increasing :-().
I think the correct fix is just to tweak the range of the randomly
distributed deltas to be plus and minus not always plus.

I have never thought about it. Seems nice idea. Thanks.

If you change to bigint then post-change results won't be strictly
comparable to pre-change results because of the difference in execution
costs.

Yes, that was my concerning too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan