From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DSM segment handle generation in background workers |
Date: | 2018-11-12 14:39:01 |
Message-ID: | 32455.1542033541@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Mon, Nov 12, 2018 at 9:34 PM Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2018-11-12 14:42:45 | Re: doc fix for pg_stat_activity.backend_type |
Previous Message | Jeremy Finzel | 2018-11-12 14:32:12 | Re: Changes to error handling for background worker initialization? |