ABAP_DESCRIPTION The table itab is a hashed table with a unique primary key and a non-unique secondary sorted key. The method refresh_itab fills the table with 100000 lines, whereby the second column contains random numbers between 1 and 10. The class measures the runtime of the statement DELETE itab , whereby a condition is set after WHERE on the column that determines the secondary key.
For demonstration purposes, the pragma ##PRIMKEY is used to suppress the syntax check warning in the first DELETE statement stating that the primary key is being used to access the internal table without its component being filled. In this access, the entire internal table must be searched linearly.
The secondary key is specified in the second DELETE statement. Since this key is not used to access the internal table after the table is filled, the secondary table key must first be constructed ( lazy update). This time is included in the DELETE statement measurement to make it considerably slower than the previous non-optimized statement.
Once the internal table is filled again, the secondary key is constructed explicitly using the method FLUSH_ITAB_KEY of the class CL_ABAP_ITAB_UTILITIES. The time measured here is largely the runtime needed to create the index.
The third DELETE statement specifies the secondary key again, but it already exists due to the previous method call. As expected, the runtime of this DELETE statement is much faster than the previous two statements. The total of this runtime and the runtime required to construct the index gives the runtime of the second DELETE statement.
The fourth DELETE statement performs the same delete operation on a sorted internal table jtab, which has the same line type and content as the previous table itab but no secondary key as its only key. The runtime is approximately the same as an access to itab using the secondary sorted key but is a little shorter since only one key needs to be administered for the internal table. If a secondary key were declared for jtab, such as a hash key for the first column, the runtime of the last two DELETE statements would be about the same. The example demonstrates that performance is improved significantly by using secondary table keys, which make it unnecessary to copy data to tables with appropriate keys. It also demonstrates, however, that the construction of a secondary index is costly. The use of lazy update also means that these costs are often incurred in unexpected places. Secondary keys are more suitable for frequent reads on large tables, rather than infrequent writes.
