>>This was done knowingly because
>>keeping transaction information would greatly increase the size of index entries - one transaction id for the transaction
>>that created the record version with the value sought, plus one for the transaction that changed the value. Obviously
>>that also increases the amount of I/O because modifying a key value modifies two index entries. A fully mature
>>record (only one version) could skip both transaction ids, at the cost of even more I/O.

Good point Ann – you have right.
I see that benefit for “m to m” with transaction ID in index
is lower then I/O cost for changing index entires on every update.
+1 for Firebird here

i see that only change which should be done is composite index suport for range scans.
And also old fearture request, like mixing asc and desc specification for composite index components.

regards,
Karol Bieniaszewski



[Non-text portions of this message have been removed]