Horton

Re: random() (was Re: New GUC to sample log queries)

Fabien COELHO <coelho@cri.ensmp.fr>

View thread View on postgr.es
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Adrien Nayrat <adrien.nayrat@anayrat.info>, Thomas Munro <thomas.munro@enterprisedb.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, vik.fearing@2ndquadrant.com, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, David Rowley <david.rowley@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-28T11:07:30Z
Lists: pgsql-hackers

Attachments

>> - lrand48 (48 bits state as 3 uint16)        is 29 ops
>>   (10 =, 8 *, 7 +, 4 >>)
>
> - xoshiro256** (256 bits states as 4 uint64) is 24 ops (18 if rot in hw)
>   8 =, 2 *, 2 +, 5 <<, 5 ^, 2 |
>
> See http://vigna.di.unimi.it/xorshift/

Small benchmark on my laptop with gcc-7.3 -O3:

  - pg_lrand48 takes 4.0 seconds to generate 1 billion 32-bit ints

  - xoshiro256** takes 1.6 seconds to generate 1 billion 64-bit ints

With -O2 it is 4.8 and 3.4 seconds, respectively. So significantly better 
speed _and_ quality are quite achievable.

Note that small attempt at optimizing these functions (inline constants, 
array replaced with scalars) did not yield significant improvements.

-- 
Fabien.

Commits

  1. Use pg_strong_random() to select each server process's random seed.

  2. Use a separate random seed for SQL random()/setseed() functions.

  3. Marginal performance hacking in erand48.c.

  4. Fix latent problem with pg_jrand48().

  5. Silence compiler warning

  6. Add log_statement_sample_rate parameter