|Subject||Re: [firebird-support] Re: Composite index - issue or not existing feature?|
>>This was done knowingly becauseGood point Ann – you have right.
>>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.
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.
[Non-text portions of this message have been removed]