On Monday, April 1, 2013, Tom Lane wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: > > The problem is that the state is maintained only to an integer number of > > milliseconds starting at 1, so it can take a number of attempts for the > > random increment to jump from 1 to 2, and then from 2 to 3. > > Hm ... fair point, if you assume that the underlying OS has a sleep > resolution finer than 1ms. Otherwise it would not matter.
Let's say you get a long stretch of increments that are all a ratio of <1.5
fold, for simplicity let's say they are all 1.3 fold. When you do
intermediate truncations of the state variable, it never progresses at all.
perl -le '$foo=1; foreach (1..10) {$foo*=1.3; print int $foo}'
perl -le '$foo=1; foreach (1..10) {$foo*=1.3; $foo=int $foo; print int
$foo}'
Obviously the true stochastic case is not quite that stark.
> No patch seen here ...
>
Sorry. I triple checked that the patch was there, but it seems like if you
save a draft with an attachment, when you come back later to finish and
send it, the attachment may not be there anymore. The Gmail Offline teams
still has a ways to go. Hopefully it is actually there this time.
Cheers,
Jeff
spin_delay_microsecond_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
