From 0dc1a8ea20820168149cedaa14e223d4d31dc4b6 Mon Sep 17 00:00:00 2001
From: "Douglas B. Rumbaugh" <doug@douglasrumbaugh.com>
Date: Sun, 6 Jul 2025 18:21:32 -0400
Subject: updates

---
 chapters/tail-latency.tex | 19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)

(limited to 'chapters/tail-latency.tex')

diff --git a/chapters/tail-latency.tex b/chapters/tail-latency.tex
index ee578a1..a0db592 100644
--- a/chapters/tail-latency.tex
+++ b/chapters/tail-latency.tex
@@ -136,7 +136,7 @@ that does not perform any re-partitioning. In this case, the technique
 provides the following worst-case insertion and query bounds,
 \begin{align*}
 I(n) &\in \Theta\left(\frac{n}{f(n)}\right) \\
-\mathscr{Q}(n) &\in \Theta\left(f(n) \cdot \mathscr{Q}\left(\frac{n}{f(n)}\right)\right)
+\mathscr{Q}(n) &\in \Theta\left(f(n) \cdot \mathscr{Q}_S\left(\frac{n}{f(n)}\right)\right)
 \end{align*}
 where $f(n)$ is the number of blocks.
 
@@ -336,19 +336,6 @@ with largest window to preemptively schedule reconstructions. Most
 of our discussion in this chapter could also be applied to leveling,
 albeit with worse results. However, BSM \emph{cannot} be used at all.
 
-\Paragraph{Nomenclature.} For the discussion that follows, it will
-be convenient to define a few terms for discussing levels relative to
-each other. While these are all fairly straightforward, to alleviate any
-potential confusion, we'll define them all explicitly here.  We define the
-term \emph{last level}, $i = \ell$, to mean the level in the dynamized
-structure with the largest index value (and thereby the most records)
-and \emph{first level} to mean the level with index $i=0$. Any level
-with $0 < i < \ell$ is called an \emph{internal level}. A reconstruction
-on level $i$ involves the combination of all blocks on that level into
-one, larger, block, that is then appended level $i+1$. Relative to some
-level at index $i$, the \emph{next level} is the level at index $i +
-1$, and the \emph{previous level} is at index $i-1$.
-
 \subsection{Concurrent Reconstructions}
 
 Our proposed approach is as follows. We will fully detach reconstructions
@@ -766,7 +753,7 @@ creating a new shard in \texttt{L2} using the two shards in \texttt{V1}'s
 The internal structure of the dynamized data structure (ignoring the
 buffer) can be thought of as a list of immutable levels, $\mathcal{V}
 = \{\mathscr{L}_0, \ldots \mathscr{L}_h\}$, where each level
-contains immutable shards, $\mathcal{L}_i = \{\mathscr{I}_0, \ldots
+contains immutable shards, $\mathscr{L}_i = \{\mathscr{I}_0, \ldots
 \mathscr{I}_m\}$. Buffer flushes and reconstructions can be thought of
 as functions, which accept a version as input and produce a new version
 as output. Namely,
@@ -1135,7 +1122,7 @@ ensure sufficient resources to fully parallelize all reconstructions
 (we'll consider resource constrained situations later).
 
 We tested -ISAM tree with the 200 million record SOSD \texttt{OSM}
-dataset~\cite{sosd}, as well as VPTree with the one million,
+dataset~\cite{sosd-datasets}, as well as VPTree with the one million,
 300-dimensional, \texttt{SBW} dataset~\cite{sbw}. For each test,
 we inserted $30\%$ of the records to warm up the structure, and then
 measured the individual latency of each insert after that. We measured
-- 
cgit v1.2.3

