Re: Poor buildfarm coverage of strong-random alternatives

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Poor buildfarm coverage of strong-random alternatives
Дата
Msg-id 8578.1546127777@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Poor buildfarm coverage of strong-random alternatives  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> Further to this ... I was just doing some measurements to see how much
> it'd add to backend startup time if we start using pg_strong_random()
> to set the initial random seed.  The answer, at least on my slightly
> long-in-the-tooth RHEL6 box, is "about 25 usec using /dev/urandom,
> or about 80 usec using OpenSSL".  So I'm wondering why configure is
> coded to prefer OpenSSL.
> I'm going to go do some timing checks on some other platforms, but
> this result suggests that we may need to question that choice.

Further testing (on Fedora, macOS, FreeBSD, and NetBSD) has confirmed
that the OpenSSL code path is 2x to 3x slower than the /dev/urandom
code path for fetching half a dozen random bytes.  So I'm still
wondering why the current preference order.  My mental model of
this is that on platforms with /dev/*random, OpenSSL's RAND_bytes
isn't doing much more than wrapping /dev/*random --- so is it
really doing anything we need?

            regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Optimize constant MinMax expressions
Следующее
От: James Coleman
Дата:
Сообщение: Using Btree to Provide Sorting on Suffix Keys with LIMIT