Re: pgbench - add pseudo-random permutation function

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Hironobu SUZUKI <hironobu@interdb.jp>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-13T15:42:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pgbench: Function to generate random permutations.

  2. Add basic support for using the POPCNT and SSE4.2s LZCNT opcodes

  3. Further improve code for probing the availability of ARM CRC instructions.

Attachments

Hello Alvaro,

> Clearly we got rid of a lot of code.  About the tests, maybe the easiest
> thing to do is "skip ... if $Config{'osname'} eq 'MSWin32'".

I tried that.

> One comment in pseudorandom_perm talks about "whitening" while the other
> talks about "scramble".  I think they should both use the same term to
> ease understanding.

Good point.

> You kept routine nbits() which is unneeded now.

Indeed.

> pgbench.c gains too many includes for my taste.  Can we put 
> pseudorandom_perm() in a separate file?

The refactoring I was thinking about for some time now is to separate 
expression evaluation entirely, not just one function, and possibly other 
parts as well. I suggest that this should wait for another submission.

> The function name pr_perm() is much too short; I think we should use a
> more descriptive name; maybe \prand_perm is sufficient?  Though I admit
> the abbreviation "perm" evokes "permission" more than "permutation" to
> me, so maybe \prand_permutation is better? (If you're inclined to
> abbreviate permutation, maybe \prand_permut?)

What about simply "permute"? Pgbench is unlikely to get another permute 
function anyway.

> I think the reference docs are not clear enough.  What do you think of
> something like this?

I agree that the documentation is not clear enough. The proposal would not 
help me to understand what it does, though. I've tried to improve the 
explanation based on wikipedia explanations about permutations.

See attached v22.

-- 
Fabien.