Skip to content
Snippets Groups Projects
Commit 6326e514 authored by Marcel Huber's avatar Marcel Huber
Browse files

updated conclusions for Index exercises

parent 54c8607f
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Indexes/README.adoc
+ 13
− 11
View file @ 6326e514
......@@ -256,7 +256,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-id1000-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-id1000-2-query-i]
----
Der *Primary-Key* Index wird aufgrund der Selektivitätsbedingung schon verwendet.
Ein _covering index_ bringt daher keinen Vorteil, sondern nur mehr Verwaltungsaufwand für das DBMS.
Ein separat erstellter _covering index_ wird hier nicht in Betracht gezogen.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -289,7 +289,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-idrange-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-idrange-2-query-i]
----
Der *Primary-Key* Index wird aufgrund der Selektivitätsbedingung schon verwendet.
Ein _covering index_ bringt daher keinen Vorteil, sondern nur mehr Verwaltungsaufwand für das DBMS.
Ein separat erstellter _covering index_ wird hier nicht in Betracht gezogen.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -323,7 +323,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-agerange-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-agerange-2-query-i]
----
Optimierung durch Index auf `age` möglich.
Zusätzliche Beschleunigung durch Erweiterung um `lastname` und `firstname`.
Eine zusätzliche Beschleunigung wird durch die Erweiterung um `lastname` und `firstname` erreicht (_covering index_).
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -405,7 +405,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-gtN-3-text]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-gtN-2-query-i]
----
Optimierung durch _covering Index_ möglich trotz Rückgabe vieler Resultate.
Optimierung durch _covering Index_ möglich trotz geringer Selektivität.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -471,7 +471,8 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-gtZ-orderby-3-text]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-gtZ-orderby-2-query-i]
----
Die Optimierung durch einen _covering Index_ bringt sehr viel, da die Werte der ausgegebenen Spalten schon im Index vorhanden sind.
Die Optimierung durch einen _covering Index_ bringt hier viel, da die Werte der ausgegebenen Spalten schon im Index vorhanden sind.
Zudem ist die Selektivität gross.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -818,7 +819,7 @@ include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-5-query
ifdef::exercise_solution[]
[example,title=""]
=====
Beim Query <<count-orderlines-lineid_gt6>> wird ein *Index Only Scan* durchgeführt weil die Selektivitätseinschränkung greift und daher die Aggregation über den Index erfolgt.
Beim Query <<count-orderlines-lineid_gt6>> reicht ein *Index Only Scan*, weil damit alle Angaben für die Ausgabe zur Verfügung stehen.
.Ausführungsplan <<count-orderlines-lineid_gt6>>
[source%autofit,sql]
......@@ -826,7 +827,7 @@ Beim Query <<count-orderlines-lineid_gt6>> wird ein *Index Only Scan* durchgefü
include::{queryoutputfile}[tags=count-orderlines-lineid_gt6-3-text]
----
Beim Query <<count-quantity_sum-orderlines-lineid_gt6>> wird ein *Index Scan* durchgeführt um damit die `quantity` Werte für die Summenberechnung zu laden.
Beim Query <<count-quantity_sum-orderlines-lineid_gt6>> muss ein *Index Scan* durchgeführt um damit die `quantity` Werte für die Summenberechnung zu laden.
.Ausführungsplan <<count-quantity_sum-orderlines-lineid_gt6>>
[source%autofit,sql]
......@@ -855,6 +856,7 @@ include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-4-query
----
include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-5-text-i]
----
Durch die Erweiterung des Index um das Feld `quantity`, kann nun auch ein reiner *Index Only Scan* durchgeführt werden.
=====
endif::exercise_solution[]
ifndef::exercise_solution[]
......@@ -946,9 +948,9 @@ ifdef::exercise_solution[]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-orderby-3-text]
----
Es lässt sich quasi keine Reduktion der Kosten ausmachen.
Nach dem Import der Datenbank wurde ein initialer `VACUUM(ANALYZE)` durchgeführt.
Danach haben wir keine Daten verändert, wodurch die erneute Durchführung eines `VACUUM` keine Veränderung der Planung oder der Laufzeit bewirkt.
In diesem Beispiel lässt sich keine Reduktion der Kosten oder der Laufzeit ausmachen.
Das ist wohl der Tatsache geschuldet, dass nach dem Import der Datenbank ein `VACUUM(ANALYZE)` durchgeführt wurde.
Da wir danach keine Daten verändert haben, bewirkt die erneute Durchführung eines `VACUUM` keine Veränderung der Planung oder der Laufzeit.
.Ausführungsplan nachher
[source%autofit,sql]
......@@ -963,7 +965,7 @@ endif::exercise_solution[]
=== Aufgabe {counter:ex_number}: `LIKE`-Queries
.[#star-products-titlelike]#Q{counter:query_number} Warum kann die Query star-products-titlelike nicht (einfach) optimiert werden?#
.[#star-products-titlelike]#Q{counter:query_number} Warum kann die Query star-products-titlelike nicht so einfach optimiert werden?#
{blank}
[source,sql]
.star-products-titlelike
......
Indexes/README.solutions.adoc
+ 13
− 11
View file @ 6326e514
......@@ -256,7 +256,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-id1000-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-id1000-2-query-i]
----
Der *Primary-Key* Index wird aufgrund der Selektivitätsbedingung schon verwendet.
Ein _covering index_ bringt daher keinen Vorteil, sondern nur mehr Verwaltungsaufwand für das DBMS.
Ein separat erstellter _covering index_ wird hier nicht in Betracht gezogen.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -289,7 +289,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-idrange-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-idrange-2-query-i]
----
Der *Primary-Key* Index wird aufgrund der Selektivitätsbedingung schon verwendet.
Ein _covering index_ bringt daher keinen Vorteil, sondern nur mehr Verwaltungsaufwand für das DBMS.
Ein separat erstellter _covering index_ wird hier nicht in Betracht gezogen.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -323,7 +323,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-agerange-3-text]
include::{queryoutputfile}[tags=lastname-firstname-customers-agerange-2-query-i]
----
Optimierung durch Index auf `age` möglich.
Zusätzliche Beschleunigung durch Erweiterung um `lastname` und `firstname`.
Eine zusätzliche Beschleunigung wird durch die Erweiterung um `lastname` und `firstname` erreicht (_covering index_).
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -405,7 +405,7 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-gtN-3-text]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-gtN-2-query-i]
----
Optimierung durch _covering Index_ möglich trotz Rückgabe vieler Resultate.
Optimierung durch _covering Index_ möglich trotz geringer Selektivität.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -471,7 +471,8 @@ include::{queryoutputfile}[tags=lastname-firstname-customers-gtZ-orderby-3-text]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-gtZ-orderby-2-query-i]
----
Die Optimierung durch einen _covering Index_ bringt sehr viel, da die Werte der ausgegebenen Spalten schon im Index vorhanden sind.
Die Optimierung durch einen _covering Index_ bringt hier viel, da die Werte der ausgegebenen Spalten schon im Index vorhanden sind.
Zudem ist die Selektivität gross.
.Ausführungsplan mit eigenem Index
[source%autofit,sql]
......@@ -818,7 +819,7 @@ include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-5-query
ifdef::exercise_solution[]
[example,title=""]
=====
Beim Query <<count-orderlines-lineid_gt6>> wird ein *Index Only Scan* durchgeführt weil die Selektivitätseinschränkung greift und daher die Aggregation über den Index erfolgt.
Beim Query <<count-orderlines-lineid_gt6>> reicht ein *Index Only Scan*, weil damit alle Angaben für die Ausgabe zur Verfügung stehen.
.Ausführungsplan <<count-orderlines-lineid_gt6>>
[source%autofit,sql]
......@@ -826,7 +827,7 @@ Beim Query <<count-orderlines-lineid_gt6>> wird ein *Index Only Scan* durchgefü
include::{queryoutputfile}[tags=count-orderlines-lineid_gt6-3-text]
----
Beim Query <<count-quantity_sum-orderlines-lineid_gt6>> wird ein *Index Scan* durchgeführt um damit die `quantity` Werte für die Summenberechnung zu laden.
Beim Query <<count-quantity_sum-orderlines-lineid_gt6>> muss ein *Index Scan* durchgeführt um damit die `quantity` Werte für die Summenberechnung zu laden.
.Ausführungsplan <<count-quantity_sum-orderlines-lineid_gt6>>
[source%autofit,sql]
......@@ -855,6 +856,7 @@ include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-4-query
----
include::{queryoutputfile}[tags=count-quantity_sum-orderlines-lineid_gt6-5-text-i]
----
Durch die Erweiterung des Index um das Feld `quantity`, kann nun auch ein reiner *Index Only Scan* durchgeführt werden.
=====
endif::exercise_solution[]
ifndef::exercise_solution[]
......@@ -946,9 +948,9 @@ ifdef::exercise_solution[]
----
include::{queryoutputfile}[tags=lastname-firstname-customers-orderby-3-text]
----
Es lässt sich quasi keine Reduktion der Kosten ausmachen.
Nach dem Import der Datenbank wurde ein initialer `VACUUM(ANALYZE)` durchgeführt.
Danach haben wir keine Daten verändert, wodurch die erneute Durchführung eines `VACUUM` keine Veränderung der Planung oder der Laufzeit bewirkt.
In diesem Beispiel lässt sich keine Reduktion der Kosten oder der Laufzeit ausmachen.
Das ist wohl der Tatsache geschuldet, dass nach dem Import der Datenbank ein `VACUUM(ANALYZE)` durchgeführt wurde.
Da wir danach keine Daten verändert haben, bewirkt die erneute Durchführung eines `VACUUM` keine Veränderung der Planung oder der Laufzeit.
.Ausführungsplan nachher
[source%autofit,sql]
......@@ -963,7 +965,7 @@ endif::exercise_solution[]
=== Aufgabe {counter:ex_number}: `LIKE`-Queries
.[#star-products-titlelike]#Q{counter:query_number} Warum kann die Query star-products-titlelike nicht (einfach) optimiert werden?#
.[#star-products-titlelike]#Q{counter:query_number} Warum kann die Query star-products-titlelike nicht so einfach optimiert werden?#
{blank}
[source,sql]
.star-products-titlelike
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment