diff --git a/semester4/dmdb/data-modelling-databases-summary.tex b/semester4/dmdb/data-modelling-databases-summary.tex
index aedb534..1ea462f 100644
--- a/semester4/dmdb/data-modelling-databases-summary.tex
+++ b/semester4/dmdb/data-modelling-databases-summary.tex
@@ -83,6 +83,7 @@ In addition, the end user does not have to worry about optimization too much. Th
 \include{parts/01_sql/main.tex}
 \include{parts/02_theory-background/main.tex}
 \include{parts/03_systems/main.tex}
+\include{parts/04_query-processing/main.tex}
 
 
 \printGlossary
diff --git a/semester4/dmdb/parts/04_query-processing/00_sorting/00_intro.tex b/semester4/dmdb/parts/04_query-processing/00_sorting/00_intro.tex
index e69de29..31c5f5c 100644
--- a/semester4/dmdb/parts/04_query-processing/00_sorting/00_intro.tex
+++ b/semester4/dmdb/parts/04_query-processing/00_sorting/00_intro.tex
@@ -0,0 +1,6 @@
+\section{Sorting}
+Sorting is crucial in DBMS due to the possibility that the user requests sorted data using an \texttt{ORDER BY} clause.
+In addtion, it can help speed up some operators.
+
+Something like Quicksort is fast, but creates many random accesses, which slows things down.
+Thus, sorting data as it is loaded into memory is beneficial, for which typically (a variant of) merge sort is used.
diff --git a/semester4/dmdb/parts/04_query-processing/00_sorting/01_merge-sort.tex b/semester4/dmdb/parts/04_query-processing/00_sorting/01_merge-sort.tex
new file mode 100644
index 0000000..1028ba9
--- /dev/null
+++ b/semester4/dmdb/parts/04_query-processing/00_sorting/01_merge-sort.tex
@@ -0,0 +1,16 @@
+\subsection{Merge Sort}
+\subsubsection{Merging Sorted Runs}
+When we sort each page on load into memory, we then have to merge all pages together, or more precisely, combine elements into pages in correct order.
+For that, we keep pointers to each pair of frames, then we first take first element of either the first or second frame, depending on which one comes first in the order,
+and copy it into the empty frame. We apply the same again to fill up the empty frame (to a threshold or fully). When the frame is full, we create a second one and link it.
+
+We do this for all pairs, then apply the same procedure to each sorted frame group, repeating this until we have a unified, sorted set of frames.
+
+If there is ever just one frame (group) left, we add an empty one implicitly and proceed normally.
+
+The cost for this is for the 1-page sorted runs (i.e. sorting the original pages) is a single pass (read + write pass).
+
+The total cost is given by $2 \cdot M \cdot N$ I/O operations, with $M$ the number of passes / phases (i.e. how many merge steps there are) and $N$ being the number of frames.
+
+For Two-Way Merge Sort, the number of passes, $M$ is given by $M = \lceil \log_2(N) \rceil + 1$,
+so the total cost to sort is $2N(\lceil \log_2 N \rceil + 1)
diff --git a/semester4/dmdb/parts/04_query-processing/00_sorting/02_replacement-sort.tex b/semester4/dmdb/parts/04_query-processing/00_sorting/02_replacement-sort.tex
new file mode 100644
index 0000000..e69de29
diff --git a/semester4/dmdb/parts/04_query-processing/00_sorting/03_sorting-with-b-trees.tex b/semester4/dmdb/parts/04_query-processing/00_sorting/03_sorting-with-b-trees.tex
new file mode 100644
index 0000000..e69de29
diff --git a/semester4/dmdb/parts/04_query-processing/main.tex b/semester4/dmdb/parts/04_query-processing/main.tex
new file mode 100644
index 0000000..e69de29