From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
In-reply-to: <alpine.DEB.2.21.1901201051270.14950@lancre>
References: <9427.1547701450@sss.pgh.pa.us>
 <alpine.DEB.2.21.1901170659210.7416@lancre> <21538.1547770868@sss.pgh.pa.us>
 <4615.1547792324@sss.pgh.pa.us> <alpine.DEB.2.21.1901180926580.26418@lancre>
 <29225.1547834182@sss.pgh.pa.us> <alpine.DEB.2.21.1901182257480.20734@lancre>
 <alpine.DEB.2.21.1901201051270.14950@lancre>
Comments: In-reply-to Fabien COELHO <coelho@cri.ensmp.fr>
	message dated "Sun, 20 Jan 2019 11:07:46 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7878.1548015981.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 20 Jan 2019 15:26:21 -0500
Message-ID: <7879.1548015981@sss.pgh.pa.us>
Precedence: bulk

Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> I'd suggest that maybe we should get rid of the use of both random()
>>> and srandom() in pgbench, and go over to letting set_random_seed()
>>> fill the pg_erand48 state directly.

> Here is a POC which defines an internal interface for a PRNG, and use it=
 =

> within pgbench, with several possible implementations which default to =

> rand48.

I seriously dislike this patch.  pgbench's random support is quite
overengineered already IMO, and this proposes to add a whole batch of
new code and new APIs to fix a very small bug.

> I must admit that I have a grudge against standard rand48:

I think this is nonsense, particularly the claim that anything in PG
cares about the lowest-order bits of random doubles.  I'm aware that
there are applications where that does matter, but people aren't doing
high-precision weather simulations in pgbench.

BTW, did you look at the question of the range of zipfian?  I confirmed
here that as used in the test case, it's generating a range way smaller
than the other ones: repeating the insertion snippet 1000x produces stats
like this:

regression=3D# select seed,rand,min(val),max(val),count(distinct val) from=
 seeded_random group by 1,2 order by 2,1;
    seed    |    rand     | min  | max  | count =

------------+-------------+------+------+-------
 1957482663 | exponential | 2000 | 2993 |   586
 1958556409 | exponential | 2000 | 2995 |   569
 1959867462 | exponential | 2000 | 2997 |   569
 1957482663 | gaussian    | 3009 | 3997 |   493
 1958556409 | gaussian    | 3027 | 3956 |   501
 1959867462 | gaussian    | 3018 | 3960 |   511
 1957482663 | uniform     | 1001 | 1999 |   625
 1958556409 | uniform     | 1000 | 1999 |   642
 1959867462 | uniform     | 1001 | 1999 |   630
 1957482663 | zipfian     | 4000 | 4081 |    19
 1958556409 | zipfian     | 4000 | 4022 |    18
 1959867462 | zipfian     | 4000 | 4156 |    23

I have no idea whether that indicates an actual bug, or just poor
choice of parameter in the test's call.  But the very small number
of distinct outputs is disheartening at least.

			regards, tom lane