Re: Spin Lock sleep resolution - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Spin Lock sleep resolution
Date
Msg-id CAMkU=1xtP+3UWL6dg10rDRtMA28zy-9ujrOxNuST_r3zOdpNxg@mail.gmail.com
Whole thread Raw
In response to Re: Spin Lock sleep resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Spin Lock sleep resolution
List pgsql-hackers
On Monday, April 1, 2013, Tom Lane wrote:
Jeff Janes <jeff.janes@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
Attachment

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: citext like searches using index
Next
From: Dimitri Fontaine
Date:
Subject: Re: in-catalog Extension Scripts and Control parameters (templates?)