ARTIClE
Internal Tables, Deleting Rows Using Keys
This example measures the runtime of the statement
DELETE ... WHERE
with various table keys.
ABAP_SOURCE_CODE
ABAP_EXEC
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 100,000 , with the second column being given random
numbers between 1 and 10.
The program measures the runtime of the statement DELETE itab ,
with a condition being set after WHERE on the column that
determines the secondary key.
For demonstration purposes, we will suppress the syntax check warning in
the first DELETE statement using Pragma
##PRIMKEY that the primary key is being used to access the
internal table without a component being specified. This access must
perform a linear scan of the entire internal table.
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 and seems 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 preceding method call. As expected, the
runtime of this DELETE statement is faster than the previous two
statements. The total of this runtime and the runtime required to
construct the index gives you the runtime of the second DELETE
statement.
The fourth DELETE statement performs the same delete operation on
a sorted internal table jtab , which as the same row 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 bit shorter since only one
key needs to be administered for the internal table. If you were to
declare a secondary key 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 you can improve performance significantly
by using secondary table keys, and therefore avoiding copying 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 read accesses to large
tables, rather than infrequent write accesses.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved