Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Mon, Nov 12, 2018 at 9:34 PM Noah Misch <noah@leadboat.com> wrote:
>> Compared to the old code, the new code requires more wall time to visit every
>> possible seed value. New code xor's the PID bits into the fastest-changing
>> timestamp bits, so only about twenty bits can vary within any given one-second
>> period. (That assumes a PID space of twenty or fewer bits; fifteen bits is
>> the Linux default.) Is that aspect of the change justified?
> Hmm, right. How about applying pg_bswap32() to one of the terms, as
> an easy approximation of reversing the bits?
I doubt that's a good idea; to a first approximation, it would mean that
half the seed depends only on the PID and the other half only on the
timestamp. Maybe we could improve matters a little by left-shifting the
PID four bits or so, but I think we still want it to mix with some
rapidly-changing time bits.
I'm not really sure that we need to do anything though. Basically,
what we've got here is a tradeoff between how many bits change over
a given timespan and how unpredictable those bits are. I don't see
that one of those is necessarily more important than the other.
regards, tom lane