At 02:29 AM 6/28/02 -0400, Claudio Valderrama C. wrote:

>
>And what's the reason that indices need numbers and dates transmogrified
>into floating point values? Isn't there any alternative approach? Two very
>close timestamps in a column could be different yet for the index they could
>become indistinguishable.
>

The transmogrification is so index nodes can be compared as unsigned
bytes without regard to data type. The complexity induced by datatype
aware index code with prefix compression would be thoroughly nasty.

Yes, two very close timestamp or double values can result in the
same index key, which is why all index retrievals are inclusive
(retrieve endpoints), the exhaustive boolean is applied after
index retrieval, and the engine doesn't (generally) trust the
exactly order from the index retrieval.

Do not that for anything other than non-double 64 bit types there
is no loss of precision in the index key. Very large (>56 bit)
quads are a potential for misunderstanding. Somebody might do
the calculation of the first date that will have precision loss
during index key computation.

The scheme is mathematically robust (proof left to the reader)
provided you don't get into (expletive deleted) index walking,
which does have an opportunity to return very close, future
timestamps in the wrong order. There also could be loss of
index precision expressing the US national debt in lire. Or
in dollars in anybody other than Arthur Andersen ever audits
Bush's books.

Jim Starkey