Message-ID: <4D549E92.4010709@2ndquadrant.com>
Date: Thu, 10 Feb 2011 21:27:30 -0500
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Stephen Frost <sfrost@snowman.net>
CC: 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>
In-Reply-To: <20110209194008.GX4116@tamriel.snowman.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Frost wrote:
> Just wondering, did you consider just calling random() twice and
> smashing the result together..?
>   

I did.  The problem is that even within the 32 bits that random() 
returns, it's not uniformly distributed.  Combining two of them isn't 
really going to solve the distribution problem, just move it around.  
Some number of lower-order bits are less random than the others, and 
which they are is implementation dependent.

Poking around a bit more, I just discovered another possible approach is 
to use erand48 instead of rand in pgbench, which is either provided by 
the OS or emulated in src/port/erand48.c  That's way more resolution 
than needed here, given that 2^48 pgbench accounts would be a scale of 
2.8M, which makes for a database of about 42 petabytes.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books