From a3c6dfb81b36e501ac84e36a842e44c55f6223f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=A1bor=20Sz=C3=A1rnyas?= Date: Tue, 19 Jun 2018 05:14:48 +0200 Subject: [PATCH] Cosmetic changes :lipstick: --- choke-points.tex | 10 +++++----- interactive.tex | 2 +- related-work.tex | 8 ++++---- workloads.tex | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/choke-points.tex b/choke-points.tex index 107eab534..71f6278cf 100644 --- a/choke-points.tex +++ b/choke-points.tex @@ -12,9 +12,9 @@ \section*{Introduction} -Choke points are a superset of~\cite{LdbcDeliverable} with the exception of CP 7.1, which was removed and replaced with a new choke point. +Choke points are a superset of~\cite{LdbcDeliverable} with the exception of CP 7.1, which was removed and replaced with a new choke point. The correlations between choke points and queries are displayed in \autoref{tab:query_choke_point}. -The connection between choke points and queries is displayed in \autoref{tab:query_choke_point}. +\todo{TODO fill language CPs for interactive} { \setlength{\tabcolsep}{.1em} @@ -92,7 +92,7 @@ \section{Join Performance} In such a situation, it is better to omit them from initial table scans, as fetching them later by row-id with a separate scan operator, which is joined to the intermediate query result, can save temporal space, and therefore I/O. Late projection does have a trade-off involving locality, since late in the plan the tuples may be in a different order, and scattered I/O in terms of tuples/second is much more expensive than sequential I/O. Late projection specifically makes sense in queries where the late use of these columns happens at a moment where the amount of tuples involved has been considerably reduced; -for example after an aggregation with only few unique group-by keys, or a top-k operator. +for example after an aggregation with only few unique group-by keys, or a top-$k$ operator. \input{query-cards/cp-2-2} @@ -423,7 +423,7 @@ \subsubsection{Language-specific notes} \item[G-CORE.] TODO -\item[SPARQL.] SPARQL requires users to explicitly enumerate variables in the \lstinline[language=sparql]{GROUP BY} clause (similarly to SQL). +\item[SPARQL.] SPARQL requires users to explicitly enumerate variables in the \lstinline[language=sql]{GROUP BY} clause (similarly to SQL). \end{description} \input{query-cards/cp-8-2} @@ -448,7 +448,7 @@ \subsubsection{Language-specific notes} \begin{description} \item[Cypher.] -Ranking can be expressed in Cypher as a sequence of ordering, collecting results and taking the top-k values of the result list. +Ranking can be expressed in Cypher as a sequence of ordering, collecting results and taking the top-$k$ values of the result list. \noindent\begin{minipage}{\linewidth} \begin{lstlisting}[language=cypher] diff --git a/interactive.tex b/interactive.tex index 00836f53f..9350dc27d 100644 --- a/interactive.tex +++ b/interactive.tex @@ -12,7 +12,7 @@ \chapter{Interactive Workload} \item \textbf{Transactional update queries.} See \autoref{sec:updates}. \end{itemize} -A detailed description of the workload is available in the 2015 \mbox{SIGMOD} paper~\cite{DBLP:conf/sigmod/ErlingALCGPPB15}. +A detailed description of the workload is available in the paper published at \mbox{SIGMOD} 2015~\cite{DBLP:conf/sigmod/ErlingALCGPPB15}. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% diff --git a/related-work.tex b/related-work.tex index aa0afef5e..6a89d2736 100644 --- a/related-work.tex +++ b/related-work.tex @@ -5,14 +5,14 @@ \chapter{Related Work} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\paragraph*{Graph processing benchmarks} +\paragraph*{Graph processing benchmarks.} Recent graph benchmarking initiatives focus on three key areas: \begin{enumerate} \item transactional workloads consisting of interactive read and update queries (OLTP) aiming at graph databases that explore small portions of the graph in each query~\cite{DBLP:conf/cidr/BarahmandG13,DBLP:conf/sigmod/ArmstrongPBC13,DBLP:journals/ase/DayarathnaS14,DBLP:conf/sigmod/ErlingALCGPPB15}, -\item graph analysis algorithms (\eg PageRank) computed in bulk, typically expressed in cluster frameworks with graph APIs, rather than high-level queries~\cite{DBLP:conf/hipc/BaderM05,DBLP:conf/bigdataconf/ElserM13,DBLP:conf/sc/NaiXTKL15,DBLP:journals/pvldb/IosupHNHPMCCSAT16}, and -\item inferencing/matching on semantic data~\cite{DBLP:journals/ws/GuoPH05,DBLP:books/sp/virgilio09/SchmidtHMPL09,DBLP:conf/semweb/MorseyLAN11,DBLP:conf/semweb/AlucHOD14,TrainBenchmarkSOSYM} +\item graph analysis algorithms (\eg PageRank) computed in bulk, typically expressed in cluster frameworks with graph APIs, rather than high-level queries~\cite{DBLP:conf/hipc/BaderM05,DBLP:conf/bigdataconf/ElserM13,DBLP:conf/sc/NaiXTKL15,DBLP:journals/pvldb/IosupHNHPMCCSAT16}, +\item pattern matching and inferencing on semantic data~\cite{DBLP:journals/ws/GuoPH05,DBLP:books/sp/virgilio09/SchmidtHMPL09,DBLP:conf/semweb/MorseyLAN11,DBLP:conf/semweb/AlucHOD14,TrainBenchmarkSOSYM} \end{enumerate} A recent technical report~\cite{lissandrini17} compares graph databases. @@ -32,6 +32,6 @@ \chapter{Related Work} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\paragraph*{LDBC Publications} +\paragraph*{LDBC publications.} A detailed list of LDBC publications is curated at~\url{http://ldbcouncil.org/publications}. \ No newline at end of file diff --git a/workloads.tex b/workloads.tex index 343d8c89a..f61d239ae 100644 --- a/workloads.tex +++ b/workloads.tex @@ -107,7 +107,7 @@ \section{Conventions for Query Definitions} are denoted with $*\mathsf{min}...\mathsf{max}$, \eg $\mathsf{replyOf}*$ or $\mathsf{knows*1 \ldots 2}$. By default, the value of $\mathsf{min}$ is 1, and the value of $\mathsf{max}$ is unlimited. - \item Aggregations are shown in dashed boxes with the type of aggregation ($\mathsf{count}$, $\mathsf{sum}$, $\mathsf{avg}$, etc.) in the upper right corner. + \item Aggregations are shown in dashed boxes with a gray strip on their top and the type of aggregation ($\mathsf{count}$, $\mathsf{sum}$, $\mathsf{avg}$, etc.) in the upper right corner. \end{itemize} \newcommand{\tuple}[1]{\langle #1 \rangle}