| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Hironobu SUZUKI <hironobu(at)interdb(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net> |
| Subject: | Re: pgbench - add pseudo-random permutation function |
| Date: | 2020-04-05 12:45:42 |
| Message-ID: | alpine.DEB.2.21.2004051422020.16227@pseudo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Attached is an attempt at improving things. I have added a explicit note and
> hijacked an existing example to better illustrate the purpose of the
> function.
A significant part of the complexity of the patch is the overflow-handling
implementation of (a * b % c) for 64 bits integers.
However this implementation is probably never used because int128 bits are
available and the one line implementation takes precedence, or the size is
small enough (less than 48 bits) so that there are no overflows with the
primes involved, thus the operation is done directly on 64 bits integers.
I could remove the implementation and replace it with a "not available on
this architecture" message, which would seldom be triggered: you would
have to use a 32 bits arch (?) and test against a table with about 262
Trows, which I guess does not exists anywhere. This approach would remove
about 40% of the code & comments.
Thougths?
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2020-04-05 13:01:10 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Previous Message | David Rowley | 2020-04-05 12:05:12 | Re: Improving connection scalability: GetSnapshotData() |