Re: [PERFORM] pgbench to the MAXINT

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: 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: 2011-02-11 02:27:30
Message-ID: 4D549E92.4010709@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-11 02:56:16 Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Previous Message Alex Hunsaker 2011-02-11 02:06:06 Re: pl/python invalidate functions with composite arguments

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2011-02-11 03:18:38 Re: [PERFORM] pgbench to the MAXINT
Previous Message Tom Lane 2011-02-10 21:12:12 Re: Why we don't want hints Was: Slow count(*) again...