At 12:09 AM 6/10/03 +0100, Artur Anjos wrote:

>Since we are talking about indexes, can you/someone point me out the way
>indexes work internally [I'm searching for something that explains if the
>indexes use versioning or not] ?

I'll be happy to answer, though you may want to check my answers with Ann in
the morning.

Updates are propagated to the indexes at verb time. This meaning that at any
given time the index may reflect values from several versions of the same
record.
There really isn't any alternative to this, as a transaction must be able
to find
its uncommitted records as well as committed records. So the index must
be treated by the engine as noisy. To avoid the obvious problems, the
engine reapplies the full boolean to every record selected by index after the
appropriate record version has been chased down.

There are other reasons that the index must be considered noisy. One is that
there is never a guarantee that uncommitted records are completely backed out.
A record is not committed by writing to disk, per se, but by first writing the
record then changing the state of the transaction on the TIP (transaction
inventory
page) from active (or limbo) to committed. Another reason is that all numeric
quantities, including dates, are mapping to double precision floating numbers,
then are mutilated so they can be compared as variable length sequences of
unsigned bytes. There are most definitely boundary conditions where several
discrete values can map to the same index key value. The engine compensates
for these by always including endpoints when doing index range retrievals then,
of course, applying the exhaustive boolean to whatever dribbles out of the
record
stream.

If it seems intuitive, you don't understand it, and need to think about it
some more.

Jim Starkey