%root: main.tex
\section{Introduction (Rewrite - 070921)}
A probabilistic database (\abbrPDB) $\pdb$ is a probability distribution $\pd$ over a (multi-) set of $\numvar$ tuples in a deterministic database $\db$.  A tuple independent probabilistic database (\abbrTIDB) $\pdb$ further restricts $\pd$ to treating each tuple in $\db$ as a bernoulli distributed random event.  Given a query $\query$ from the class of positive relational algebra queries ($\raPlus$), the goal is to compute the expectation ($\expct\pbox{\poly\inparen{\vct{X}}}$) of each output tuple $\tup$, where $\poly\inparen{\vct{X}}$ is the lineage polynomial of $\tup$ parameterized by $\vct{X}$, the set of $\numvar$ variables annotating the base tuples of $\pdb$.

The lesser problem of simply computing $\query$ over a deterministic database is itself known to be \sharpwonehard in the general case.  This is seen in such queries as counting $k$-cliques and $k$-way joins, where the superlinear runtime is parameterized in $k$.  This result is (obviously) unsatisfying when considering query runtime over \abbrPDB\xplural, since it \emph{entirely} ignores the complexity of intensional evaluation (computing $\expct\pbox{\poly\inparen{\vct{X}}}$).  A natural question is whether or not we can quantify the runtime of the intensional evaluation of $\poly\inparen{\vct{X}}$ separately from the complexity of deterministic query evaluation.  \Cref{fig:two-step} illustrates one way to do this.

The model of computation in \cref{fig:two-step} views \abbrPDB query processing as two steps.  As depicted, the first step consists of computing $\query$ over a $\abbrPDB$, which is essentially the deterministic computation of both the query output and $\poly(\vct{X})$\footnote{Note that, assuming standard $\raPlus$ query algorithms, computing the lineage polynomial of $\tup$ is upperbounded by the runtime of deterministic query evaluation of $\tup$.}.  The second step consists of computing $\expct\pbox{\poly(\vct{X})}$. Such a model of computation is nicely followed by set-\abbrPDB semantics \cite{DBLP:series/synthesis/2011Suciu} (where e.g. intensional evaluation is itself a separate computational step; further, computing $\expct\pbox{\poly\inparen{\vct{X}}}$ in extensional evaluation occurs as a separate step of each operator in the query tree, and therefore implies that both concerns can be separated) and also by that of semiring provenance \cite{DBLP:conf/pods/GreenKT07} (where the $\semNX$-DB first computes the annotation via the query, and then the polynomial is evaluated on a specific valuation), and further, in this work the model lends itself nicely in separating the deterministic computation from the probability computation.  

The problem of computing $\query(\pdb)$ has been extensively studied in the context of \emph{set}-\abbrPDB\xplural, where the lineage is represented as a propositional formula rather than a polynomial.\footnote{For the case when $\query$ is in the class of $\raPlus$ and $\pdb$ is a \abbrTIDB, the lineage propositional formula is essentially a polynomial with conjunction ($\wedge$) as the polynomial multiplication operator and disjunction ($\vee$) as the polynomial addition operator.}  The semantics of evaluating $\query(\pdb)$ in this setting require each output tuple in $\query(\pdb)$ appears at most once in the result with its corresponding marginal probability $\expct\pbox{\poly\inparen{\vct{X}}}$.  Dalvi and Suicu showed that the complexity of the query computation problem over set-\abbrPDB\xplural is \sharpphard in general, and proved that a dichotomy exists for this problem, where the runtime of $\query(\pdb)$ is either polynomial or \sharpphard for any polynomial step one.  Since the hardness is in the size of the input ($\numvar$), fine grained complexity analysis of step two will not reduce the hardness results from the \sharpphard complexity class for any parameterized complexity class.  To overcome this result, one can allow for approximation which reduces the problem to a quadratic upper bound.

There exist some queries for which \emph{bag}-\abbrPDB\xplural are a more natural fit.  One such query is the count query, where one might desire to compute the expected multiplicity ($\expct\pbox{\poly\inparen{\vct{X}}}$) of a result tuple $\tup$.  The semantics of $\query(\pdb)$ in bag-\abbrPDB\xplural allow for output tuples to appear \emph{more} than once.

For the case of bags, should we allow for approximation in the setting of bag-\abbrPDB\xplural, this paper shows that we can \emph{guarantee} runtime of $\query(\pdb)$ to be linear in the deterministic runtime of $\query$.  We further show in this paper that it is \emph{not} the case in general that the intensional step of $\query(\pdb)$ is linear in the runtime of the deterministic query $\query$.