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.
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 |