Attempted a work around for the broken background color when using \underbrace in lstlisting environment; it's better, but needs tweaking.

intro-rewrite-070921.tex

@@ -133,7 +133,7 @@ Specifically, depending on what hardness result/conjecture we assume, we get var
 
 What our lower bound in the third row says is that one cannot get more than a polynomial improvement over essentially the trivial algorithm for~\Cref{prob:expect-mult}.
  However, this result assumes a hardness conjecture that is not as well studied as those in the first two rows of the table (see \Cref{sec:hard} for more discussion on the hardness assumptions). Further, we note that existing results\footnote{
- Consider the known results for the problem of counting $k$-cliques~\cite{10.5555/645413.652181},~\cite{CHEN20061346}, where for a query $\query$ over database $\tupset$ that counts the number of $k$-cliques, such results imply a runtime of $\omega_k\inparen{\numvar}$, our lower bounds would hold.
+ Consider the known results for the problem of counting $k$-cliques~\cite{10.5555/645413.652181},~\cite{CHEN20061346}, where for a query $\query$ over database $\tupset$ that counts the number of $k$-cliques, the results show a runtime of $\Omega_k\inparen{\numvar}$, implying our lower bounds would hold.
  }
   already imply the claimed lower bounds if we were to replace the $\qruntime{\optquery{\query}, \tupset, \bound}$ by just $\numvar$ (indeed these results follow from known lower bounds for deterministic query processing). Our contribution is to then identify a family of hard queries where deterministic query processing is `easy' but computing the expected multiplicities is hard. 
 

main.tex

@@ -33,6 +33,7 @@
 \usepackage{graphicx}
 \usepackage{listings}
 %%%%%%%%%% SQL + proveannce listing settings
+\usepackage{mdframed}
 \lstdefinestyle{psql}
 {
 tabsize=2,

mult_distinct_p.tex

@@ -52,9 +52,12 @@ SELECT 1 FROM T $t_1$, R r, T $t_2$
 WHERE $t_1$.city = r.city1 AND $t_2$.city = r.city2
 \end{lstlisting}
 as $R$.  The query $\query^k$ then becomes
+\mdfdefinestyle{underbrace}{topline=false, rightline=false, bottomline=false, leftline=false, backgroundcolor=black!15!white, innerbottommargin=0pt}
+\begin{mdframed}[style=underbrace]
 \begin{lstlisting}
 SELECT COUNT(*) FROM $\underbrace{R\text{ JOIN }R\text{ JOIN}\cdots\text{JOIN }R}_{k\rm\ times}$
 \end{lstlisting}          
+\end{mdframed}
 \noindent Consider again the \abbrCTIDB instance $\pdb$ of~\Cref{fig:two-step} and, for our hard instance, let $\bound = 1$.  $\pdb$ generalizes to one compatible to~\Cref{def:qk} as follows. Relation $T$ has $n$ tuples corresponding to each vertex for $i$ in $[n]$, each with probability $\prob$ and $R$ has tuples corresponding to the edges $\edgeSet$ (each with probability of $1$).\footnote{Technically, $\poly_{G}^\kElem(\vct{X})$ should have variables corresponding to tuples in $R$ as well, but since they always are present with probability $1$, we drop those. Our argument also works when all the tuples in $R$ also are present with probability $\prob$ but to simplify notation we assign probability $1$ to edges.}
 In other words, this instance $\tupset$ contains the set of $\numvar$ unary tuples in $T$ (which corresponds to $\vset$) and $\numedge$ binary tuples in $R$ (which corresponds to $\edgeSet$).
 Note that this implies that $\poly_{G}^\kElem$ is indeed a $1$-\abbrTIDB lineage polynomial. % for a \abbrTIDB \abbrPDB.