Re: DSM segment handle generation in background workers

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