Re: [PERFORM] pgbench to the MAXINT
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Gurjeet Singh <singh.gurjeet@gmail.com>
Cc: Satoshi Nagayasu <snaga@uptime.jp>, Greg Smith <greg@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Euler Taveira de Oliveira <euler@timbira.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2013-01-29T10:12:41Z
Lists: pgsql-hackers, pgsql-performance
On 28.01.2013 23:30, Gurjeet Singh wrote: > On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu<snaga@uptime.jp> wrote: > >> 2012/12/21 Gurjeet Singh<singh.gurjeet@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