Re: [HACKERS] pgbench enhancements
> Tatsuo Ishii <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 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. >> > >> >> >> 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 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. > > > > > 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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. > Was there a previous patch posted for this? I don't recall seeing it. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgbench enhancements
Tatsuo Ishii <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
