Re: rand48 replacement

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: rand48 replacement
Дата
Msg-id alpine.DEB.2.22.394.2105241509200.165418@pseudo
обсуждение исходный текст
Ответ на Re: rand48 replacement  (Aleksander Alekseev <aleksander@timescale.com>)
Ответы Re: rand48 replacement  (Aleksander Alekseev <aleksander@timescale.com>)
Re: rand48 replacement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Skip partition tuple routing with constant partition key
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments