ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Internal Tables - Overview

Row-Based Administration Costs of Internal Tables

In addition to the basic memory requirement described in Memory requirement for deep data objects required to administrate internal tables in table headers, additional memory is required to administrate each individual row, so permitting optimized access to the individual rows. This internal administration of individual rows has two variants:

A table index administrates the logical order of table rows. The additional memory requirement is 6 bytes per table row on average. Exception: If the logical order matches the physical order in the table body, no additional memory is required for the index.

Hash administration allows table rows to be accessed by hashing the corresponding key components. The additional memory requirement is 18 bytes per table row on average as long as the table is not accessed using the DELETE or SORT statements. Following access of this type, an average of 30 bytes is required per table row.

How a table row is administrated depends on the table category and any existing secondary table keys. The table category determines the basic administration of the rows of an internal table (table index for index tables, hash administration for hashed tables). Each additional secondary table key introduces additional row administration (table index for sorted keys, hash administration for hashed keys).

Indexes are therefore created in the following cases:

As the primary table index of a standard table for managing the order arising from index operations. However, the order in the index has no relation to the content of the table rows. The index is only for the optimization of index accesses. Content searches cannot be optimized and always lead to a linear search of all table rows.

As the primary table index of a sorted table or as the secondary table index of a sorted secondary table of any other table for managing the order of table rows in accordance with the sorted primary or secondary table key. The order of table rows is determined by the view of the table rows defined by the sorted table keys. This defines an order for the rows of the table that can be used for optimized access by the binary search.

Hash administrations are created in the following cases:

For the primary table key of a hash table or for a secondary hash key of any other table. They do not permit index access. They can only be used for optimized access with a fully specified table key.

If secondary table keys are used, additional memory costs may be incurred.

An internal table with at least one ambiguous sorted secondary key needs an additional 8 bytes per table row for the basic costs of administrating possible duplicates. These additional basic costs are incurred only once and not for each table key.

Additional memory costs are incurred if a secondary key needs to be updated following a change to the content of the internal table. Again, this costs a few bytes per table row but varies greatly depending on the number of changes made.

Other versions: 7.31 | 7.40 | 7.54

Examples

A standard table with a secondary hash key that is exclusively filled with APPEND requires:

No additional memory for the primary index since the logical and physical orders are the same

18 bytes per row for the hash administration of the secondary key

Following an access using DELETE or SORT, the memory requirement per row jumps to 6 bytes for the primary index and 30 bytes for the hash administration.

A sorted table with a secondary hash key and two non-unique sorted secondary keys requires:

6 bytes per row for the primary index

18 or 30 bytes per row for the hash administration of the secondary hash key

6 bytes per row and key for the sorted secondary key from the moment from which it is used

8 bytes per row because there is at least one non-unique sorted secondary key