Kbase P144112: Is there a performance impact on having a large number of empty fields in a table?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
06/04/2009 |
|
Status: Unverified
GOAL:
Is there a performance impact on having a large number of empty fields in a table?
GOAL:
How does having larger table definitions impact ABL performance?
GOAL:
Does the number of fields in a table affect execution times?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
OpenEdge Category: Language (4GL/ABL)
FIX:
For overall performance, it is unlikely that having a large number of empty fields in a table will have a noticeable impact on performance.
The impact on the data size is minimal due to the fact that the OpenEdge database engine uses a variable-length record format; an empty field consumes only a single byte of storage space in the record. As a result, the performance of read/write operations on the actual record will also be minimal.
The impact here might be noticeable if:
- The effective size of the data in the record is tiny, and a large number of fields are empty. In this case the overhead by the empty fields may be a significant portion of the record size.
- The usually empty fields are indexed. This will slow down record create and delete operations, as these indexes will still need to be updated. Record updates are less likely to be effected, as they only require updating the indexes on modified fields.
Read operations on the schema definitions will be more severely affected, as the definitions of the empty fields are still processed at this point.
However, these operations normally only takes place at compile time, or at runtime when creating dynamic objects that directly reference database schema (temp-table create-like, dynamic queries).
Normally, compared to the time spent executing other logic (in order to process the actual data), the time spent fetching schema data is several orders of magnitude less. Therefore it's unlikely that a larger schema will have much impact at run-time.
At compile time, the impact may be noticeable depending on the number of procedures or classes that have static references to the table. But compile-time performance is not often seen as a concern.