On 28.01.2013 23:30, Gurjeet Singh wrote:
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu<sn...@uptime.jp> wrote:
2012/12/21 Gurjeet Singh<singh.gurj...@gmail.com>:
The patch is very much what you had posted, except for a couple of
differences due to bit-rot. (i) I didn't have to #define
MAX_RANDOM_VALUE64
since its cousin MAX_RANDOM_VALUE is not used by code anymore, and (ii) I
used ternary operator in DDLs[] array to decide when to use bigint vs int
columns.
Please review.
As for tests, I am currently running 'pgbench -i -s 21474' using
unpatched pgbench, and am recording the time taken;Scale factor 21475 had
actually failed to do anything meaningful using unpatched pgbench. Next
I'll
run with '-s 21475' on patched version to see if it does the right thing,
and in acceptable time compared to '-s 21474'.
What tests would you and others like to see, to get some confidence
in
the patch? The machine that I have access to has 62 GB RAM, 16-core
64-hw-threads, and about 900 GB of disk space.
I have tested this patch, and hvae confirmed that the columns
for aid would be switched to using bigint, instead of int,
when the scalefactor>= 20,000.
(aid columns would exeed the upper bound of int when sf>21474.)
Also, I added a few fixes on it.
- Fixed to apply for the current git master.
- Fixed to surpress few more warnings about INT64_FORMAT.
- Minor improvement in the docs. (just my suggestion)
I attached the revised one.
Looks good to me. Thanks!
Ok, committed.
At some point, we might want to have a strtoll() implementation in src/port.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
