Date: Wed, 9 Feb 2011 14:40:08 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Euler Taveira de Oliveira <euler@timbira.com>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] pgbench to the MAXINT
Message-ID: <20110209194008.GX4116@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DRp5/Sds4nAqvQzf"
Content-Disposition: inline
In-Reply-To: <4D525281.1000201@2ndquadrant.com>
User-Agent: Mutt/1.5.20 (2009-06-14)


--DRp5/Sds4nAqvQzf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greg,

* Greg Smith (greg@2ndquadrant.com) wrote:
> I took that complexity out and just put a hard line
> in there instead:  if scale>=3D20000, you get bigints.  That's not
> very different from the real limit, and it made documenting when the
> switch happens easy to write and to remember.

Agreed completely on this.

> It turns out that even though I've been running an i386 Linux on
> here, it's actually a 64-bit CPU.  (I think that it has a 32-bit
> install may be an artifact of Adobe Flash install issues, sadly)  So
> this may not be as good of a test case as I'd hoped. =20

Actually, I would think it'd still be sufficient..  If you're under a
32bit kernel you're not going to be using the extended registers, etc,
that would be available under a 64bit kernel..  That said, the idea that
we should care about 32-bit systems these days, in a benchmarking tool,
is, well, silly, imv.

> 1) A look into the expected range of the rand() function suggests
> the glibc implementation normally proves 30 bits of resolution, so
> about 1 billion numbers.  You'll have >1B rows in a pgbench database
> once the scale goes over 10,000.  So without a major overhaul of how
> random number generation is treated here, people can expect the
> distribution of rows touched by a test run to get less even once the
> database scale gets very large. =20

Just wondering, did you consider just calling random() twice and
smashing the result together..?

> I added another warning paragraph
> to the end of the docs in this update to mention this.  Long-term, I
> suspect we may need to adopt a superior 64-bit RNG approach,
> something like a Mersenne Twister perhaps.  That's a bit more than
> can be chewed on during 9.1 development though.

I tend to agree that we should be able to improve the random number
generation in the future.  Additionally, imv, we should be able to say
"pg_bench version X isn't comparable to version Y" in the release notes
or something, or have seperate version #s for it which make it clear
what can be compared to each other and what can't.  Painting ourselves
into a corner by saying we can't ever make pgbench generate results that
can't be compared to every other released version of pgbench just isn't
practical.

> 2) I'd rate odds are good there's one or more corner-case bugs in
> \setrandom or \setshell I haven't found yet, just from the way that
> code was converted.  Those have some changes I haven't specifically
> tested exhaustively yet.  I don't see any issues when running the
> most common two pgbench tests, but that's doesn't mean every part of
> that 32 -> 64 bit conversion was done correctly.

I'll take a look. :)

	Thanks,

		Stephen

--DRp5/Sds4nAqvQzf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1S7ZgACgkQrzgMPqB3kii4MACcDtbFuc2YEay/ujOK8aQl3VIr
RYwAnA8keyFUaJ9HJEQGJHNGyl3pXnHQ
=o7WE
-----END PGP SIGNATURE-----

--DRp5/Sds4nAqvQzf--