Message-ID: <5107A099.6030208@vmware.com>
Date: Tue, 29 Jan 2013 12:12:41 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
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>
Subject: Re: [PERFORM] pgbench to the MAXINT
References: <4D27C4E5.5000609@2ndquadrant.com> <4D2A965A.3000603@timbira.com>
	<4D2AC273.3010709@2ndquadrant.com> <4D2CCCD9.802@timbira.com>
	<4D35DF33.6060901@2ndquadrant.com> <4D5017DE.90404@2ndquadrant.com>
	<4D525281.1000201@2ndquadrant.com>
	<20110209194008.GX4116@tamriel.snowman.net>
	<4D549E92.4010709@2ndquadrant.com> <12987.1297394318@sss.pgh.pa.us>
	<4D5BCDFD.2010703@2ndquadrant.com>
	<CABwTF4WdTZuooQVHSOSLrWWfyMQeBcGwLKzSBSsTuQxVY8hDTQ@mail.gmail.com>
	<CAA8sozcukQOfmio7RGPUX3HnAHxPs=VV22u1xkaE49L0dHGm0Q@mail.gmail.com>
	<CABwTF4WpWqYHWYU9TaRmefDYDBWxFjjNJ0TWadGzBAP-mGxuKw@mail.gmail.com>
In-Reply-To: 
 <CABwTF4WpWqYHWYU9TaRmefDYDBWxFjjNJ0TWadGzBAP-mGxuKw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers