On Fri, 28 Nov 2003, Marc G. Fournier wrote:
> On Fri, 28 Nov 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > I'm suspecting that the issue is amplified by load on the server itself
> >
> > That would fit right in with my idea that the failure occurs when the
> > process loses its timeslice partway through gettimeofday(). Heavier
> > load would presumably make it more likely to lose the CPU.
>
> I'm posting to the freebsd lists about it, see if they have anything to
> say ...
Just got my first response on this, and, in fact, this is 'acceptable
behaviour' to a certain extent ... there is a kernel tuneable called
kern.timecounter.method, that is either 1 or 0:
0 sacrifice precision in favor of faster code execution
1 return the more precise time (the same as calling microtime() or
nanotime()).
The intent of the getmicrotime() and getnanotime() functions is to
enforce the user's preference for timer accuracy versus execution time.
Now, reading the man page, there seems to be a 'microtime' vs
'getmicrotime' function ... these might be preferable to using
gettimeofday on FreeBSD?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
