| From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 64-bit size pgbench |
| Date: | 2010-01-29 07:29:30 |
| Message-ID: | 20100129162930.DC53.52131E4D@oss.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Attached is a patch that fixes a long standing bug in pgbench: it won't
> handle scale factors above ~4000 (around 60GB) because it uses 32-bit
> integers for its computations related to the number of accounts, and it
> just crashes badly when you exceed that. This month I've run into two
> systems where that was barely enough to exceed physical RAM, so I'd
> expect this to be a significant limiting factor during 9.0's lifetime.
> A few people have complained about it already in 8.4.
+1 for the fix.
Do we also need to adjust "tuples done" messages during dataload?
It would be too verbose for large scale factor. I think a message
every 1% is reasonable.
if (j % 10000 == 0)
fprintf(stderr, INT64_FORMAT " tuples done.\n", j);
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2010-01-29 07:32:53 | Re: can somebody execute this query on Oracle 11.2g and send result? |
| Previous Message | Takahiro Itagaki | 2010-01-29 07:15:54 | Re: Largeobject Access Controls (r2460) |