Re: rand48 replacement

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: rand48 replacement
Date: 2021-05-24 13:22:58
Message-ID: alpine.DEB.2.22.394.2105241509200.165418@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Aleksander,

>> - better software engineering
>> - similar speed (slightly slower)
>> - better statistical quality
>> - quite small state
>> - soundness
>
> Personally, I think your patch is great.

Thanks for having a look!

> Speaking of the speed I believe we should consider the performance of
> the entire DBMS in typical scenarios, not the performance of the single
> procedure.

Sure. I tested a worst-case pgbench script with only "\set i random(1,
100000000)" on a loop, the slowdown was a few percents (IFAICR < 5%).

> I'm pretty sure in these terms the impact of your patch is neglectable
> now, and almost certainly beneficial in the long term because of better
> randomness.
>
> While reviewing your patch I noticed that you missed test_integerset.c.
> Here is an updated patch.

Indeed. Thanks for the catch & the v2 patch!

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-24 13:45:32 Re: CALL versus procedures with output-only arguments
Previous Message houzj.fnst@fujitsu.com 2021-05-24 13:15:35 RE: Skip partition tuple routing with constant partition key