pgbench - add pseudo-random permutation function

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello,

This patch adds a pseudo-random permutation function to pgbench. It allows
to mix non uniform random keys to avoid trivial correlations between
neighboring values, hence between pages.

The function is a simplistic form of encryption adapted to any size, using
a few iterations of scramble and scatter phases. The result is not
cryptographically convincing, nor even statistically, but it is quite
inexpensive and achieves the desired result. A computation costs 0.22 µs
per call on my laptop, about three times the cost of a simple function.

Alternative designs, such as iterating over an actual encryption function
or using some sbox, would lead to much more costly solutions and complex
code.

I also join a few scripts I used for testing.

--
Fabien.

pgbench-prp-func-1.patch (15K) Download Attachment
prp_init.sql (340 bytes) Download Attachment
prp_analyse.sql (364 bytes) Download Attachment
prp_gen_vals.sql (480 bytes) Download Attachment
prp_test_2.sql (336 bytes) Download Attachment
prp_test_3.sql (340 bytes) Download Attachment
prp_test_4.sql (394 bytes) Download Attachment
prp_test_5.sql (448 bytes) Download Attachment
prp_test_6.sql (526 bytes) Download Attachment
prp_test_n.sql (382 bytes) Download Attachment
prp_perf.sql (418 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Hironobu SUZUKI
Hi Fabian,

I reviewed `pgbench-prp-func-1.patch` and found an incomplete
implementation.


In the pseudorandom_perm function, I confirmed that the scramble and
scatter operations are mathematically bijections. Therefore, this
function is mathematically correct.

However, the implementation of the scatter operation in this patch
overflows in many cases if the variable:size is 38 bit integer or
greater. Because the variable:size and the item of the array:primes[]
which stores 27-29 bit integers are multiplicated. If overflow occurs,
the scatter operation does not satisfy bijective.

I did a sampling inspection, whose conditions are the variable:size is
1099511627773 (= 40 bit integer) and the variable:seed is 5432. Even
with very few samples, I found a huge number of collisions as shown below:

pr_perm(409749816, 1099511627773, 5432) = pr_perm(491041141,
1099511627773, 5432) = pr_perm(729171766, 1099511627773, 5432) =
pr_perm(849775914, 1099511627773, 5432) = 22445482629,
pr_perm(45609644, 1099511627773, 5432) = pr_perm(174005122,
1099511627773, 5432) = pr_perm(811754941, 1099511627773, 5432) =
pr_perm( 1131176891, 1099511627773, 5432) = 10626826534,
and so on.

There are two ways to resolve this issue. The first one is to reduce the
maximum value can be set for the variable:size. The second one is to add
a modular multiplication function to avoid overflow. I made a patch
including the function that can be calculated modular multiplication
without overflow, and attached this mail.
(I also attached a simple test suite of the function I added.)


In the others parts of the original patch, I could apply the patch and
did tests without trouble; the documentations and comments are well
except one comment in the function shown below:

 >> (1) scramble: partial xors on power-or-2 subsets

I could not understand this meaning when I read it at the first time.


Best regards,


On 2018/07/28 15:03, Fabien COELHO wrote:

>
> Hello,
>
> This patch adds a pseudo-random permutation function to pgbench. It
> allows to mix non uniform random keys to avoid trivial correlations
> between neighboring values, hence between pages.
>
> The function is a simplistic form of encryption adapted to any size,
> using a few iterations of scramble and scatter phases. The result is not
> cryptographically convincing, nor even statistically, but it is quite
> inexpensive and achieves the desired result. A computation costs 0.22 µs
> per call on my laptop, about three times the cost of a simple function.
>
> Alternative designs, such as iterating over an actual encryption
> function or using some sbox, would lead to much more costly solutions
> and complex code.
>
> I also join a few scripts I used for testing.
>


pgbench-prp-func-2.patch (13K) Download Attachment
modular_multiplicate.c (2K) Download Attachment
modular_multiplicate.dat (1K) Download Attachment
modular_multiplicate_test.sh (442 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello Hironobu-san,

> I reviewed `pgbench-prp-func-1.patch` and found an incomplete implementation.

Indeed, thanks a lot for the debug, and the proposed fix!

I'm going to work a little bit more on the patch based on your proposed
changes, and submit a v3, hopefully soon.

--
Fabien.

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3
In reply to this post by Hironobu SUZUKI

Hello Hironobu-san,

> However, the implementation of the scatter operation in this patch overflows
> in many cases if the variable:size is 38 bit integer or greater. Because the
> variable:size and the item of the array:primes[] which stores 27-29 bit
> integers are multiplicated. If overflow occurs, the scatter operation does
> not satisfy bijective.

Indeed. Again, thanks for the debug! As you contributed some code, I added
you as a co-author in the CF entry.

Attached a v3, based on your fix, plus some additional changes:
  - explicitly declare unsigned variables where appropriate, to avoid casts
  - use smaller 24 bits primes instead of 27-29 bits
  - add a shortcut for multiplier below 24 bits and y value below 40 bits,
    which should avoid the manually implemented multiplication in most
    practical cases (tables with over 2^40 rows are pretty rare...).
  - change the existing shortcut to look a the number of bits instead of
    using 32 limits.
  - add a test for minimal code coverage with over 40 bits sizes
  - attempt to improve the documentation
  - some comments were updates, hopefully for the better

The main idea behind the smaller primes is to avoid the expensive modmul
implementation on most realistic cases.

--
Fabien.

pgbench-prp-func-3.patch (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello Hironobu-san,

Here is a v4, based on our out-of-list discussion:
  - the mask function is factored out
  - the popcount builtin is used if available

> Attached a v3, based on your fix, plus some additional changes:
> - explicitly declare unsigned variables where appropriate, to avoid casts
> - use smaller 24 bits primes instead of 27-29 bits
> - add a shortcut for multiplier below 24 bits and y value below 40 bits,
>   which should avoid the manually implemented multiplication in most
>   practical cases (tables with over 2^40 rows are pretty rare...).
> - change the existing shortcut to look a the number of bits instead of
>   using 32 limits.
> - add a test for minimal code coverage with over 40 bits sizes
> - attempt to improve the documentation
> - some comments were updates, hopefully for the better
--
Fabien.

pgbench-prp-func-4.patch (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Hironobu SUZUKI
Hi Fabian-san,

I reviewed 'pgbench-prp-func/pgbench-prp-func-4.patch'.

I could apply it and did the TAP test successfully. I could not find
typo in the documentations and comments.

To make sure, I checked the new routine which contains the
__builtin_popcountll() function on Linux + gcc 7.3.1 and I confirmed
that it works well.

I thinks this patch is fine.


Best regards,


On 2018/09/16 21:05, Fabien COELHO wrote:

>
> Hello Hironobu-san,
>
> Here is a v4, based on our out-of-list discussion:
>   - the mask function is factored out
>   - the popcount builtin is used if available
>
>> Attached a v3, based on your fix, plus some additional changes:
>> - explicitly declare unsigned variables where appropriate, to avoid casts
>> - use smaller 24 bits primes instead of 27-29 bits
>> - add a shortcut for multiplier below 24 bits and y value below 40 bits,
>>   which should avoid the manually implemented multiplication in most
>>   practical cases (tables with over 2^40 rows are pretty rare...).
>> - change the existing shortcut to look a the number of bits instead of
>>   using 32 limits.
>> - add a test for minimal code coverage with over 40 bits sizes
>> - attempt to improve the documentation
>> - some comments were updates, hopefully for the better
>


Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

> I reviewed 'pgbench-prp-func/pgbench-prp-func-4.patch'. [...] I thinks
> this patch is fine.

Thanks!

You may consider turning it "ready" in the CF app, so as to see whether
some committer agrees with you.

--
Fabien.

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Thomas Munro-3
On Wed, Sep 19, 2018 at 7:07 AM Fabien COELHO <[hidden email]> wrote:
> > I reviewed 'pgbench-prp-func/pgbench-prp-func-4.patch'. [...] I thinks
> > this patch is fine.

modular_multiply() is an interesting device.  I will leave this to
committers with a stronger mathematical background than me, but I have
a small comment in passing:

+#ifdef HAVE__BUILTIN_POPCOUNTLL
+ return __builtin_popcountll(n);
+#else /* use clever no branching bitwise operator version */

I think it is not enough for the compiler to have
__builtin_popcountll().  The CPU that this is eventually executed on
must actually have the POPCNT instruction[1] (or equivalent on ARM,
POWER etc), or the program will die with SIGILL.  There are CPUs in
circulation produced in this decade that don't have it.  I have
previously considered something like this[2], but realised you would
therefore need a runtime check.  There are a couple of ways to do
that: see commit a7a73875 for one example, also
__builtin_cpu_supports(), and direct CPU ID bit checks (some
platforms).  There is also the GCC "multiversion" system that takes
care of that for you but that worked only for C++ last time I checked.

[1] https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT
[2] https://www.postgresql.org/message-id/CAEepm%3D3g1_fjJGp38QGv%2B38BC2HHVkzUq6s69nk3mWLgPHqC3A%40mail.gmail.com

--
Thomas Munro
http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello Thomas,

> modular_multiply() is an interesting device.  I will leave this to
> committers with a stronger mathematical background than me, but I have
> a small comment in passing:

For testing this function, I have manually commented out the various
shortcuts so that the manual multiplication code is always used, and the
tests passed. I just did it again.

> +#ifdef HAVE__BUILTIN_POPCOUNTLL
> + return __builtin_popcountll(n);
> +#else /* use clever no branching bitwise operator version */
>
> I think it is not enough for the compiler to have
> __builtin_popcountll().  The CPU that this is eventually executed on
> must actually have the POPCNT instruction[1] (or equivalent on ARM,
> POWER etc), or the program will die with SIGILL.

Hmmm, I'd be pretty surprised: The point of the builtin is to delegate to
the compiler the hassle of selecting the best option available, depending
on target hardware class: whether it issues a cpu/sse4 instruction is
not/should not be our problem.

> There are CPUs in circulation produced in this decade that don't have
> it.

Then the compiler, when generating code that is expected to run for a
large class of hardware which include such old ones, should not use a
possibly unavailable instruction, or the runtime should take
responsability for dynamically selecting a viable option.

My understanding is that it should always be safe to call __builtin_XYZ
functions when available. Then if you compile saying that you want code
specific to cpu X and then run it on cpu Y and it fails, basically you
just shot yourself in the foot.

> I have previously considered something like this[2], but realised you
> would therefore need a runtime check.  There are a couple of ways to do
> that: see commit a7a73875 for one example, also
> __builtin_cpu_supports(), and direct CPU ID bit checks (some platforms).
> There is also the GCC "multiversion" system that takes care of that for
> you but that worked only for C++ last time I checked.

ISTM that the purpose of a dynamic check would be to have the better
hardware benefit even when compiling for a generic class of hardware which
may or may not have the better option.

This approach is fine for reaching a better performance/portability
compromise, but I do not think that it is that useful for pgbench to go to
this level of optimization, unless someone else takes care, hence the
compiler builtin.

An interesting side effect of your mail is that while researching a bit on
the subject I noticed __builtin_clzll() which helps improve the nbits code
compared to using popcount. Patch attached uses CLZ insted of POPCOUNT.

--
Fabien.

pgbench-prp-func-5.patch (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Thomas Munro-3
On Wed, Sep 26, 2018 at 8:26 PM Fabien COELHO <[hidden email]> wrote:

> > modular_multiply() is an interesting device.  I will leave this to
> > committers with a stronger mathematical background than me, but I have
> > a small comment in passing:
>
> For testing this function, I have manually commented out the various
> shortcuts so that the manual multiplication code is always used, and the
> tests passed. I just did it again.
>
> > +#ifdef HAVE__BUILTIN_POPCOUNTLL
> > + return __builtin_popcountll(n);
> > +#else /* use clever no branching bitwise operator version */
> >
> > I think it is not enough for the compiler to have
> > __builtin_popcountll().  The CPU that this is eventually executed on
> > must actually have the POPCNT instruction[1] (or equivalent on ARM,
> > POWER etc), or the program will die with SIGILL.
>
> Hmmm, I'd be pretty surprised: The point of the builtin is to delegate to
> the compiler the hassle of selecting the best option available, depending
> on target hardware class: whether it issues a cpu/sse4 instruction is
> not/should not be our problem.

True, it selects based on what you tell it:

$ cat x.c
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char *argv[])
{
        printf("%d\n", __builtin_popcount(atoi(argv[1])));
}
$ gdb -q a.out
...
(gdb) disass main
...
   0x00000000004005a4 <+39>: callq  0x4005c0 <__popcountdi2>
...
$ gcc -mpopcnt x.c
$ gdb -q a.out
...
(gdb) disass main
...
   0x000000000040059f <+34>: popcnt %eax,%eax
...

I'd forgotten one detail... we figure out if need to tell it that we
have SSE4.2 instructions explicitly in the configure script:

checking which CRC-32C implementation to use... SSE 4.2 with runtime check

We enable -msse4.2 just on the one file that needs it, in src/port/Makefile:

pg_crc32c_sse42.o: CFLAGS+=$(CFLAGS_SSE42)

On this CentOS machine I see:

gcc ... -msse4.2 ... -c pg_crc32c_sse42.c -o pg_crc32c_sse42_srv.o

That is necessary because most people consume PostgreSQL through
packages from distributions that have to work on an Athlon II or
whatever, so we can't just use -msse4.2 for every translation unit.
So it becomes our job to isolate small bits of code that use newer
instructions, if it's really worth the effort to do that, and supply
our own runtime checks and provide a fallback.

> > There are CPUs in circulation produced in this decade that don't have
> > it.
>
> Then the compiler, when generating code that is expected to run for a
> large class of hardware which include such old ones, should not use a
> possibly unavailable instruction, or the runtime should take
> responsability for dynamically selecting a viable option.

Right.  Our problem is that if we didn't do our own runtime testing,
users of (say) Debian and RHEL packages (= most users of PostgreSQL)
would effectively never be able to use things like CRC32 instructions.
None of that seems worth it for something like this.

> An interesting side effect of your mail is that while researching a bit on
> the subject I noticed __builtin_clzll() which helps improve the nbits code
> compared to using popcount. Patch attached uses CLZ insted of POPCOUNT.

It's annoying that fls() didn't make it into POSIX along with ffs().
On my system it compiles to a BSR instruction, just like
__builtin_clz().

--
Thomas Munro
http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello,

> That is necessary because most people consume PostgreSQL through
> packages from distributions that have to work on an Athlon II or
> whatever, so we can't just use -msse4.2 for every translation unit.
> So it becomes our job to isolate small bits of code that use newer
> instructions, if it's really worth the effort to do that, and supply
> our own runtime checks and provide a fallback.

Ok. That was my understanding so as to improve the portability/performance
compromise. I do not think that pgbench is worth the effort on this
particular point.

> [...] None of that seems worth it for something like this.

Indeed.

So, am I right to deducing that you are satisfied with the current status
of the patch, with the nbits implementation either based on popcount (v4)
or clz (v5) compiler intrinsics? I think that the clz option is better.

--
Fabien.

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Michael Paquier-2
On Wed, Sep 26, 2018 at 01:20:49PM +0200, Fabien COELHO wrote:
> So, am I right to deducing that you are satisfied with the current status of
> the patch, with the nbits implementation either based on popcount (v4) or
> clz (v5) compiler intrinsics? I think that the clz option is better.

Fabien, please note that v5 does not apply, so I moved this patch to
next CF, waiting on author.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3
>     PostgreSQL Hackers <[hidden email]>
> Subject: Re: pgbench - add pseudo-random permutation function
>
> On Wed, Sep 26, 2018 at 01:20:49PM +0200, Fabien COELHO wrote:
>> So, am I right to deducing that you are satisfied with the current status of
>> the patch, with the nbits implementation either based on popcount (v4) or
>> clz (v5) compiler intrinsics? I think that the clz option is better.
>
> Fabien, please note that v5 does not apply,

Indeed, tests interact with 92a0342 committed on Thursday.

Here is a rebase of the latest version based on CLZ. According to basic
test I made, the underlying hardware instruction seems to be more often
available.

> so I moved this patch to next CF, waiting on author.

I'm going to change its state to "Needs review".

--
Fabien.

pgbench-prp-func-6.patch (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Hironobu SUZUKI
Hi,

I reviewed pgbench-prp-func-6.patch.

(1) modular_multiply()
In modular_multiply(), the numbers of digits of inputs are checked in
order to determine using the interleaved modular multiplication
algorithm or not. However, the check condition absolutely depends on the
implementation of pseudorandom_perm() even though modular_multiply() is
a general function.

I think it is better that pseudorandom_perm() directly checks the
condition because it can be worked efficiently and modular_multiply()
can be used in general purpose.

(2) pseudorandom_perm() and 001_pgbench_with_server.pl
Reading the discussion of __builtin_xxx functions, I remembered another
overflow issue.

pseudorandom_perm() uses the Donald Knuth's linear congruential
generator method to obtain pseudo-random numbers. This method, not only
this but also all linear congruential generator methods, always overflows.

If we do not need to guarantee the portability of this code, we do not
care about the result of this method because we just use *pseudo* random
numbers. (In fact, I ignored it before.) However, since we have to
guarantee the portability, we have to calculate it accurately. I
therefore implemented the function dk_lcg() and rewrote pseudorandom_perm().

Just to be sure, I made a python code to check the algorithm of
pseudorandom_perm() and run it.
Fortunately, my python code and pseudorandom_perm() which I rewrote
returned the same answers, so I rewrote the answers in
001_pgbench_with_server.pl.



I attached the new patch `pgbench-prp-func-7.patch`, the python code
`pseudorandom_perm.py`, and the pr_perm check script file
`pr_perm_check.sql`.

Best regards,


On 2018/10/01 12:19, Fabien COELHO wrote:

>>     PostgreSQL Hackers <[hidden email]>
>> Subject: Re: pgbench - add pseudo-random permutation function
>>
>> On Wed, Sep 26, 2018 at 01:20:49PM +0200, Fabien COELHO wrote:
>>> So, am I right to deducing that you are satisfied with the current
>>> status of
>>> the patch, with the nbits implementation either based on popcount
>>> (v4) or
>>> clz (v5) compiler intrinsics? I think that the clz option is better.
>>
>> Fabien, please note that v5 does not apply,
>
> Indeed, tests interact with 92a0342 committed on Thursday.
>
> Here is a rebase of the latest version based on CLZ. According to basic
> test I made, the underlying hardware instruction seems to be more often
> available.
>
>> so I moved this patch to next CF, waiting on author.
>
> I'm going to change its state to "Needs review".
>


pr_perm_check.sql (358 bytes) Download Attachment
pseudorandom_perm.py (1K) Download Attachment
pgbench-prp-func-7.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello Hironobu-san,

> I reviewed pgbench-prp-func-6.patch.

Thanks.

> (1) modular_multiply()
> In modular_multiply(), the numbers of digits of inputs are checked in order
> to determine using the interleaved modular multiplication algorithm or not.
> However, the check condition absolutely depends on the implementation of
> pseudorandom_perm() even though modular_multiply() is a general function.
>
> I think it is better that pseudorandom_perm() directly checks the condition
> because it can be worked efficiently and modular_multiply() can be used in
> general purpose.

You moved the shortcut to the caller. Why not, it removes one modulo
operation and avoids the call altogether.

> (2) pseudorandom_perm() and 001_pgbench_with_server.pl
> Reading the discussion of __builtin_xxx functions, I remembered another
> overflow issue.
>
> pseudorandom_perm() uses the Donald Knuth's linear congruential generator
> method to obtain pseudo-random numbers. This method, not only this but also
> all linear congruential generator methods, always overflows.

> If we do not need to guarantee the portability of this code,

ISTM that we do not need such changes: the code is already portable
because standard C unsigned operations overflow consistently and this is
what it really expected for the linear congruential generator.

If an alternate implementation should be provided, given the heavy cost of
the modular multiplication function, it would be only for those
architectures which fails, detected at configure time. I would not go into
this without an actual failing architecture & C compiler.

Also, the alternate implementation should not change the result, so
something looks amiss in your version. Moreover, I'm unclear how to
implement an overflow multiply with the safe no overflow version.

Here is a v8 which:
  - moves the shortcut to the caller
  - changes the r formula as you did
  - does nothing about Knuth's formula, as nothing should be needed
  - fixes tests after Peter's exit status changes

--
Fabien.

pgbench-prp-func-8.patch (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Hironobu SUZUKI
Hello,

 > Also, the alternate implementation should not change the result, so
 > something looks amiss in your version. Moreover, I'm unclear how to
 > implement an overflow multiply with the safe no overflow version.
(snip)

I made an honest mistake. I had assumed the modulo number of Knuth's LCG
is (2 ^ 64 - 1).


BTW, I found other overflow issue.
In pseudorandom_perm(), `modular_multiply() + (key >> LCG_SHIFT)` may
overflow if the result of modular_multiply() is large. Therefore, I've
improved it.

Also, I've simplified Step 5 in modular_multiply().


I attached pgbench-prp-func-9.patch.

Best regards,

pgbench-prp-func-9.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

Hello Hironobu-san,

> In pseudorandom_perm(), `modular_multiply() + (key >> LCG_SHIFT)` may
> overflow if the result of modular_multiply() is large. Therefore, I've
> improved it.

> Also, I've simplified Step 5 in modular_multiply().

Attached is a v10, where I have:
  - updated some comments
  - the + cannot overflow because size is taken from a signed int
    and the added value is small thanks to the shift.
    I have put back the simple formula and added a comment about it.
  - added a few test cases, and fix the associated checks

--
Fabien.

pgbench-prp-func-10.patch (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Hironobu SUZUKI
Hi Fabian-san,

I reviewed 'pgbench-prp-func/pgbench-prp-func-10.patch'.


On 2018/10/24 12:55, Fabien COELHO wrote:

>
> Hello Hironobu-san,
>
>> In pseudorandom_perm(), `modular_multiply() + (key >> LCG_SHIFT)` may
>> overflow if the result of modular_multiply() is large. Therefore, I've
>> improved it.
>
>> Also, I've simplified Step 5 in modular_multiply().
>
> Attached is a v10, where I have:
>   - updated some comments
>   - the + cannot overflow because size is taken from a signed int
>     and the added value is small thanks to the shift.
>     I have put back the simple formula and added a comment about it.
>   - added a few test cases, and fix the associated checks
>

I agree your discussion before.

I checked the tests you added in this patch and I confirmed that there
is no problem.

I thinks this patch is fine.

Best regards,

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Fabien COELHO-3

> I thinks this patch is fine.

Thanks!

Hopefully some committer will pick it up at some point.

--
Fabien.

Reply | Threaded
Open this post in threaded view
|

Re: pgbench - add pseudo-random permutation function

Alvaro Herrera-9
In reply to this post by Fabien COELHO-3
Can you please pgindent this?

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

12