Und hier ist die Theorie zur
Praxis:
DB2 Explain schätzt für das teuerste
Test-Select auf die
umdefinierte Tabelle in unkomprimierter bzw. komprimierter Form folgende den Aufwände:
| unkomprimiert | zeilenkomprimiert | |
| Gesamtaufwand | 111.757,9453125000 Timeron | 49.764,9921875000 Timeron | 45% |
| CPU-Aufwand | 6.189.640.704 Anweisungen | 7.847.347.712 Anweisungen | 127% |
| Ein-/Ausgabeaufwand | 107.542 E/As | 44.191 E/As | 41% |
| Aufwand der ersten Zeile | 1.755,8646240234 Timeron | 786,0233154297 Timeron | 44% |
Danach wäre der Aufwand für die Ausführung des analysierten Selects für die verdichtete erheblich niedriger. Auf den ersten Blick passt das nicht so richtig zur Praxis, die bestenfalls einen Gleichstand ergab.
Bei näherem Hinsehen wird klar, dass der Gesamtaufwand nahezu komplett durch den geschätzten I/O bestimmt wird. Eine Verringerung des I/O bewirkt fast 10-mal stärker eine Reduzierung des Gesamtaufwandes als eine entsprechende Verminderung der CPU-Anweisungen. Das begründet große Performance-Vorteile für Zugriffe auf stark komprimierbare Tabellen.
Für unkomprimierte Tabellen, die komplett in den Buffer passen, entfällt der Aufwand für I/O. Dagegen entsteht für den Zugriff auf das (ebenfalls komplett im RAM abgelegte) komprimierte Analogon ein zusätzlicher CPU-Aufwand durch Dekomprimierung, der nun ungebremst zu einer entsprechenden Erhöhung des Gesamtaufwandes führt.
Die Theorie zeigt also, dass sich in
besagter Praxis die Select-Anweisungen hauptsächlich aus dem Buffer bedient haben müssen.
Übrigens: der Aufwand für E/A entspricht hier der Größe der jeweiligen Tabelle in Anzahl 4K-Pages (npages).
ap127
Eigentlich wollte ich nur einen Langläufer testen - eine SQL-Query in der drei Tabellen mit ca. 300.000 Zeilen und eine Tabelle mit mehr als 10.000 Zeilen gejoint werden. Anlass war meine Beobachtung, dass das Komprimieren großer Tabellen neben Speicher
Aufgenommen: Apr 15, 19:43