Tom Lane wrote:
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
I understand the reasoning for the backoff (as of the discussion on
2003-08-05), but is there any particular reason for using floating
point operations here ? Maybe a modulo would be just as good (or
better since it doesn't involve the FPU) ?
My goodness that's a hardware-dependent proposal. Shall we discuss
how many CPUs there are where an integer division is *slower* than
a floating-point op?
Hi Tom:
Do you have one in mind, or is this a straw man? :-)
Why do you think that a couple of FP ops here are a problem, anyway?
This is a code path where we've already yielded the processor, so
by definition the repetition rate has to be pretty low.
Yielded the processor? Or yielded the lock? With 32 active threads
contending for the lock, but first contending for the FPU, one could see
how it might be relevant.
I think I agree with you that this won't be the only problem, however,
the FPU may not need to contribute to the problem?
The other problem with using modulo is that it makes the result depend
mostly on the low-order bits of the random() result, rather than mostly
on the high-order bits; with lower-grade implementations of random(),
the lower bits are materially less random than the higher. Now
admittedly high-grade randomness is probably not too important for this
specific context, but I dislike putting in poor coding practices that
someone might see and copy without thinking...
If this was a serious problem, there is the >> operator. I see it as a
poor coding practice to make assumptions about which bits are most
"random" in a call to random(). If anybody fixes the problem you
describe, then the opposite may become true. Perhaps the lowest bits are
the most random. If random() is broken, random() should be fixed. Coding
in specific implementation details about specific implementations of
random() is just as bad. :-)
IMHO, use of FPU should be avoided wherever possible on any platform. On
some platforms, the FPU may be fully implemented in software. My memory
is faint, but I think SPARC v7 either implemented / in software, or had
a trap that implemented it in software.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
