mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-07-27 21:29:09 +02:00
[DMDB] Sorting, selection, projection, aggregation
This commit is contained in:
@@ -0,0 +1,6 @@
|
||||
Two terms important here are \textit{logical selection}, which describes \bi{what} we want to select and \textit{physical selection},
|
||||
which describes \bi{how} the algorithm or procedure works that actually retrieves, or filters, the data.
|
||||
|
||||
The options include an \textit{file scan}, where we scan the entire file and thus the I/O cost is the number of pages in each relation.
|
||||
Alternatively, we can use \textit{index scan}, where we use an index to retrieve the matching rows.
|
||||
The cost then of course depends on the index used and if said index can even be used to generate the resulsts needed. We will cover that in more detail now.
|
||||
@@ -0,0 +1,22 @@
|
||||
\subsubsection{Index Scan}
|
||||
\begin{itemize}
|
||||
\item \bi{Hash Index}: {\color{ForestGreen} $\tco{1}$, we read the bucket and possibly the overflow buckets.} {\color{red} Can only be used for equality predicates}
|
||||
\item \bi{B+ Tree Index}: $\tco{\log_F(N) + X}$, with $F$ fanout, $N$ the number of leaf nodes and $X$ the ratio of number of selected tuples and tuples per page.
|
||||
{\color{red} $X$ can be up to 1 per selected tuple with an unclustered index}. Optimization: we could sort the RIDs.
|
||||
\item \bi{Bitmap Index}: $\tco{\text{size of bitmap index}} + X$, {\color{red} $X$ depends on clustering again}
|
||||
\end{itemize}
|
||||
|
||||
The I/O cost for B+ Tree Index Scan is $\texttt{tree height} + \texttt{\# leaf pages} + \texttt{\# file pages}$
|
||||
|
||||
\inlineexample{Computation example}
|
||||
Given a relation $R$ with $N =$ one million records. There are 100 records on a page and we have a B+ Tree with the data entries $<k, rid>$
|
||||
and it has a capacity of 500 data entries on each leaf. It also has 3 internal node levels and a fill factor of $0.67$.
|
||||
|
||||
Then the cost is computed as follows:
|
||||
\begin{itemize}
|
||||
\item 3 internal nodes to parse, $\ceil{\log_F(N)}$
|
||||
\item Number of result records = $1,000,000 * 1\% = 10,000$ (this is the selectivity)
|
||||
\item Number of leaf pages pointing to the results records = $10,000 / (500 \cdot 0.67) = 30$
|
||||
\item Number of pages in the heap file that hold the result records $= 10,000 / 100 = 30$
|
||||
\end{itemize}
|
||||
Then, the total cost is $3 + 30 + 100 = 133$
|
||||
@@ -0,0 +1,15 @@
|
||||
\subsubsection{Index Matching}
|
||||
The predicates in the queries can contain comparison operators, as well as \texttt{AND} and \texttt{OR}, allowing conjuncts and disjuncts.
|
||||
|
||||
Index Matching is the process of choosing the proper index for the task.
|
||||
For conjuncts only, we can use:
|
||||
\begin{itemize}
|
||||
\item \bi{Hash Indexes}. Constraints: Only equality operations and predicate has to contain all index attributes
|
||||
\item \bi{B+-Tree}. Constraints: The attributes in the predicates need to be prefixes of the search key
|
||||
\end{itemize}
|
||||
|
||||
Here, the indexes need to match \bi{every} predicate in the disjunction.
|
||||
For instance, if we have a hash index on $A$ and a B+ tree on $B$, and the query is \verb|A = 7 OR B > 5|.
|
||||
In that case, we can either file scan or use both indexes (we fetch the RIDs and take the union)
|
||||
|
||||
However, index matching is a hard problem.
|
||||
Reference in New Issue
Block a user