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: | Raw Message | Whole Thread | 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) |