The improvements to logic surrounding API calls,
including SQL statements, are listed in this section.
Improved Overall Range Performance
Range performance was improved by using NXTKEY()/PRVKEY() instead of GTKEY()/LTKEY()
when possible.
We discovered that range performance could be enhanced using NXTKEY() instead of GTKEY() to skip over records that did not meet range and/or filter criteria during range operations. Because
NXTKEY() cannot always be substituted, the logic now determines when it must use GTKEY().
Improved Open-Ended Key Estimation Performance
The Estimate Key function, ESTKEY(), was improved such that if either the upper or lower limit of the range is opened-ended, efficiencies are gained. By open-ended we mean that the estimated number of keys is either greater than a lower limit or smaller than an upper limit.
A NULL pointer is now passed in for the upper or lower limit when this condition is met and the tree manipulations for the open-ended limit can be skipped. The appropriate percentile for the
opened-ended limit is simply assigned: 0 for no lower limit or 100 for an opened-ended upper limit. The tree manipulations consist of a binary search using the First Key routine, FRCKEY(),to estimate the percentile of a given limit. To permit some rounding to be accommodated, we actually use a range from 0 to 1000 instead of 0 to 100. Think baseball batting averages.
Improved Performance of Descending Range Searches
We observed unnecessary operations comparing a range performed in ascending order versus descending order. When the key values that satisfy a range are contiguous, the range logic can stop searching whenever an internal get next key operation finds a key that does not satisfy the range criteria. The descending range logic, PRVRNG()/PRVVRNG(), did not take advantage of this optimization, and made unnecessary calls to low-level key routines.
This modification applies the optimization to the descending order range routines. The key values satisfying a range will be contiguous if:
All the criteria are equality constraints, CTIX_EQ. or
All but the last criteria are equality constraints and the last of the criteria does not use a NOT condition (i.e., it is not a CTIX_NE or CTIX_NOTBET).
Trailing segments, if any, that have no range criteria do not affect whether or not the keys satisfying the range criteria are contiguous.
Persisted Current Index Buffer Node for NXTKEY and PRVKEY
Operations
The NXTKEY() and PRVKEY() functions already remember the offset of the current index node so that subsequent calls can continue scanning from the previous key position. Now, c-treeACE remembers the address of the index buffer that holds the current node.
Whenever the current index node offset is saved for later use, the current index buffer address is also saved. When NXTKEY() or PRVKEY() find that the current index buffer address has been set, these functions lock that index buffer and then verify that the buffer still contains the same node. If so, the function continues processing using the locked index buffer. If not, the function calls the node management routines as usual, and remembers the address of the returned node buffer.
Set Node Name Optimization
The set node name function, SETNODE(), was optimized to take no action if the specified node name is same as current node name. This avoids a client network call to the c-treeACE Server and avoids an entry written to the transaction log buffer.
Key-Level Lock logic
Performance was enhanced when the calling thread owns all the pending key-level locks.
In some situations repeated calls were made to a function which attempts to resolve key-level locks without any cleanup occurring. This cleanup function checks each of the key-level locks in a leaf node to determine if the associated transactions have terminated. When a key-level lock is associated with a transaction that has been committed or aborted, the key-level lock is removed and the key value stays (committing an add or aborting a delete) or is removed (committing a delete or aborting an add). But if a thread is executing a long transaction, it may be repeatedly calling this cleanup routine
without any effect when the key-level locks for a node all belong to the calling thread.
We now immediately detect when all the key-level locks belong to the calling thread, and return without checking each of the key-level locks. Also, we have enhanced the key-level locking cleanup performance when calling thread is executing a NXTKEY operation. To improve the efficiency of
ctclup() when it is called as part of a NXTKEY() operation, ctclup() has been modified to only perform the cleanup necessary to satisfy the NXTKEY operation.
Improve Performance of Range Retrieval
An enhancement improves the performance of range retrieval with equality search on a full unique key. When a range search is performed on a unique index and the range criteria specify an equality match on all segments of the key, we can call EQLKEY() instead of GTEKEY(). For a partitioned file global-unique index that does not cover the partition key, this greatly improves performance when many active partitions exist. This is because EQLKEY() can use the global unique partition host index to find the partition that contains the key value.
Prior to this modification, the range search function called GTEKEY(), which required calling