From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgbench enhancements |
Date: | 2006-07-26 22:42:41 |
Message-ID: | 20060727.074241.73653242.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2006-07-26 23:16:25 | Re: GUC with units, details |
Previous Message | Andrew Dunstan | 2006-07-26 22:26:11 | Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to |