Compare commits

..

11 Commits
v0.1.1 ... main

Author SHA1 Message Date
29d1784813 add authors comment 2024-05-07 00:35:28 +03:00
1cd6f44af8 fix issues 2024-05-07 00:34:35 +03:00
97934dd5ac Merge branch 'jorenchik-main' 2024-05-07 00:31:40 +03:00
f3345f7cc1 fix: skill issue 2024-05-07 00:31:13 +03:00
Kristofers Solo
f6128287ad Create LICENSE 2024-05-07 00:31:13 +03:00
1bf92654da chore: add actions
add main file
2024-05-07 00:31:13 +03:00
3f4261e918 minor changes 2024-05-07 00:31:13 +03:00
928bd8554f refactor: use columns 2024-05-07 00:31:07 +03:00
jorenchik
a9bb553cf3 export 2024-05-06 22:59:41 +03:00
jorenchik
226bf240d6 fix seeks 2024-05-06 22:59:26 +03:00
jorenchik
5f19876f7a minor fixes 2024-05-06 22:11:48 +03:00
2 changed files with 17 additions and 5 deletions

BIN
export/DB2Cheatsheet.pdf Normal file

Binary file not shown.

View File

@ -87,9 +87,10 @@ Simplified version (to get the idea)
for each tuple tr in r: (for each tuple ts in s: test pair (tr, ts))
```
// TODO: Add seek information
Block transfer cost: $n_r dot b_s + b_r$ block transfers would be required,
where $b_r$ -- blocks in relation $r$, same for $s$.
where $b_r$ -- blocks in relation $r$, same for $s$. Each scan of the inner
relation requires one seek, and the scan of the outer relation requires one seek
per block, leading to a total of $2 dot b_r$ seeks.
== Block-nested join
@ -275,7 +276,8 @@ The concept of conflict equivalence leads to the concept of conflict
serializability. We say that a schedule $S$ is *conflict serializable* if it is
conflict equivalent to a serial schedule.
=== Serializability graph
// TODO: rename to precedence
=== Precedence graph
Simple and efficient method for determining the conflict seriazability of a
schedule. Consider a schedule $S$. We construct a directed graph, called a
@ -310,6 +312,15 @@ locking protocol. We say that a locking protocol ensures conflict
serializability if and only if all legal schedules are *conflict serializable*;
in other words, for all legal schedules the associated $->$ relation is acyclic.
*Recoverable* schedule is one where, for each pair of transactions $T_i$ and
$T_j$ such that $T_j$ reads a data item previously written by $T_i$, the commit
operation of $T_i$ appears before the commit operation of $T_j$.
*Cascadeless* schedule is one where, for each pair of transactions $T_i$ and
$T_j$ such that $T_j$ reads a data item previously written by $T_i$, the commit
operation of $T_i$ appears before the read operation of $T_j$. Every cascadeless
schedule is also recoverable.
=== Lock-based
*Shared Lock* -- If a transaction $T_i$ has obtained a shared-mode lock (denoted
@ -475,7 +486,8 @@ $B=5;T_"disk"=0.001;T_"seek"=0.1$
=== Nested-Loop Join Method
+ Nested-loop join:
- For each pattern in $r_1$, search all patterns in $r_2$.
+ Total Combinations: $75435 dot 11456=$
+ Total Combinations: $75435 dot 11456$
+ Time Calculation for Nested-Loop Join:
- Reading and searching time for each combination: $0.001+0.1=0.101 "ms"$
- Total time: $75435 dot 11456 dot 0.101 = 87282519.36 "ms"$
- Total time: $75435 dot 11456 dot 0.101 = 87282519.36 "ms"$ [Authors comment:
seems fishy]