Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] pgbench to the MAXINT

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


In response to

pgsql-performance by date

Next:From: Alex VinnikDate: 2013-01-29 14:24:10
Subject: Re: Simple join doesn't use index
Previous:From: Merlin MoncureDate: 2013-01-29 02:31:32
Subject: Re: Simple join doesn't use index

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2013-01-29 10:15:41
Subject: Re: pg_basebackup with -R option and start standby have problems with escaped password
Previous:From: Amit KapilaDate: 2013-01-29 09:58:34
Subject: Re: Performance Improvement by reducing WAL for Update Operation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group