Thread: pgbench enhancements
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. enjoy, -- Tatsuo Ishii SRA OSS, Inc. Japan
> 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