Trade-offs in Static and Dynamic Evaluation of Hierarchical Queries

We investigate trade-offs in static and dynamic evaluation of hierarchical queries with arbitrary free variables. In the static setting, the trade-off is between the time to partially compute the query result and the delay needed to enumerate its tuples. In the dynamic setting, we additionally consider the time needed to update the query result under single-tuple inserts or deletes to the database. Our approach observes the degree of values in the database and uses different computation and maintenance strategies for high-degree (heavy) and low-degree (light) values. For the latter it partially computes the result, while for the former it computes enough information to allow for on-the-fly enumeration. We define the preprocessing time, the update time, and the enumeration delay as functions of the light/heavy threshold. By appropriately choosing this threshold, our approach recovers a number of prior results when restricted to hierarchical queries. We show that for a restricted class of hierarchical queries, our approach achieves worst-case optimal update time and enumeration delay conditioned on the Online Matrix-Vector Multiplication Conjecture.


Introduction
The problems of static evaluation, i.e., computing the result of a query [Yan81,OZ15,KNS17,NPRR18], and dynamic evaluation, i.e., maintaining the result of a query under inserts and deletes of tuples to the input relations [Koc10, CY12, K + 14, BKS17a, IUV17, KNN + 19a], are fundamental to relational databases.
We consider a refinement of these two problems that decomposes the overall evaluation time into the preprocessing time, which is used to compute a data structure that represents the query result, the update time, which is the time to update the data structure under inserts and deletes to the input data, and the enumeration delay, which is the time between the start of the enumeration process and the output of the first tuple in the query result, the time between outputting any two consecutive tuples, and the time between outputting the last tuple and the end of the enumeration process [DG07]. In this paper we investigate the relationship between preprocessing, update, and delay and answer questions such as, how much preprocessing time is needed to achieve sublinear enumeration delay.
We consider the static and dynamic evaluation of a subclass of α-acyclic queries called hierarchical queries: Definition 1.1 [SORK11,BKS17a]. A conjunctive query is hierarchical if for any two variables, their sets of atoms in the query are either disjoint or one is contained in the other. Hierarchical queries enjoy highly desirable tractability properties in a variety of computational settings, making them an important yardstick for database computation. The notion of hierarchical queries used in this paper has been initially introduced in the context of probabilistic databases [SORK11]. The Boolean conjunctive queries without repeating relation symbols that can be computed in polynomial time on tuple-independent probabilistic databases are hierarchical; non-hierarchical queries are hard for #P [SORK11]. This dichotomy was extended to non-Boolean queries with negation [FO16]. Hierarchical queries are the conjunctive queries whose provenance admits a factorized representation where each input tuple occurs a constant number of times; any factorization of the provenance of a non-hierarchical query would require a number of occurrences of the provenance of some input tuple dependent on the input database size [OZ12]. For hierarchical queries without self-joins, this read-once factorized representation explains their tractability for exact probability computation over probabilistic databases. In the Massively Parallel Computation (MPC) model, the hierarchical queries admit parallel evaluation with one communication step [KS11b]. The r-hierarchical queries, which are conjunctive queries that become hierarchical by repeatedly removing the atoms whose complete set of variables occurs in another atom, can be evaluated in the MPC model using a constant number of steps and optimal load on every single database instance [HY19]. Hierarchical queries also admit one-step streaming evaluation in the finite cursor model [GGL + 09]. Under updates, the q-hierarchical queries are the conjunctive queries that admit constant-time update and delay [BKS17a]. The q-hierarchical queries are a proper subclass of both the free-connex α-acyclic and hierarchical queries. Besides being hierarchical, the following condition holds on the free variables of a q-hierarchical query: if the set of atoms of a free variable is strictly contained in the set of another variable, then the latter must also be free.
In this paper we characterize trade-offs in the static and dynamic evaluation of hierarchical queries. In the static setting, we are interested in the trade-off between preprocessing time and enumeration delay. In the dynamic case, we additionally consider the update time. Section 2 states our main result in the static setting and explains how it recovers prior results on static query evaluation. Section 3 gives our main result in the dynamic setting and discusses its implications. These two sections also overview prior work on static and dynamic query evaluation. Section 4 introduces the basic notions underlying our approach. Sections 5-7 detail the preprocessing, enumeration, and update stages of our approach. Section 8 shows that for a restricted class of hierarchical queries, our approach achieves worst-case optimal update time and enumeration delay, conditioned on the Online Matrix-Vector Multiplication Conjecture. We illustrate our approach using two detailed examples in Section 9 and conclude in Section 10. The proofs of the main theorems in Sections 2 and 3 and the propositions in Sections 5-7 are deferred to Appendices A-E. The proofs of the propositions in Sections 4 and 8 can be found in the technical report [KNOZ19].
A preliminary version of this work appeared in PODS 2020 [KNOZ20]. We extended it as follows. We overviewed in greater depth and breadth the related work for a more complete picture of the state of the art (Sections 1-3). We added new motivating examples to demonstrate that our approach achieves better overall evaluation time than existing approaches both in the static and dynamic cases (Sections 2 and 3). We included necessary background on the computational model and width measures (Section 4). We added a detailed description of the algorithms (Union and Product) used by the enumeration procedure of our approach (Section 6). We included the procedures for major and minor rebalancing in case of updates and gave the procedure for the maintenance of a query result under sequences of updates (Section 7). Finally, we included complete proofs of the main results and the main statements on the preprocessing, enumeration, and update stages of our approach (Appendices A-E).

Trade-offs in Static Query Evaluation
Our main result for the static evaluation of hierarchical queries is stated next.
Theorem 2.1. Given a hierarchical query with static width w, a database of size N , and ϵ ∈ [0, 1], the query result can be enumerated with O(N 1−ϵ ) delay after O(N 1+(w−1)ϵ ) preprocessing time.
The measure w, previously introduced as s ↑ [OZ15], generalizes the fractional hypertree width [Mar10] from Boolean to arbitrary conjunctive queries. This is equivalent to the FAQ-width in case of Functional Aggregate Queries over a single semiring [AKNR16]. In this paper, we refer to this measure as the static width of the query (Definition 4.6).  Figure 1 depict the preprocessing time and respectively the enumeration delay. The middle plot in Figure 1 visualizes the trade-off between the two components. Our approach achieves each blue point and each point on the blue line. Prior approaches are represented by the blue points in the trade-off space. By appropriately setting ϵ, our approach recovers prior results restricted to hierarchical queries. For ϵ = 0, both the preprocessing time and the delay become O(N ), as for α-acyclic queries [BDG07]. For ϵ = 1, we obtain O(N w ) preprocessing time and O(1) delay as for conjunctive queries [OZ15]. Free-connex acyclic queries are a special class of queries that enjoy linear preprocessing time and constant delay [BDG07]. We recover this result as follows. First, we observe that any free-connex hierarchical query has static width w = 1. This means that the preprocessing time remains O(N ) regardless of ϵ; we then choose ϵ = 1 to obtain O(1) delay. For bounded-degree databases, i.e., where each value appears at most c times for some constant c = N β , first-order queries admit O(N ) preprocessing time and O(1) delay [DG07,KS11a]. We recover the O(1) delay using ϵ = 1. The next example demonstrates how the complexities of our approach in the static case imply lower overall evaluation time than existing approaches.
Example 2.2. Consider the hierarchical query Q(A, C) = R(A, B), S(B, C). Let us assume that the input relations are of size N . Then, it takes quadratic time to compute the list of tuples in the query result of Q. (As it will become clearer later, this query has static width 2, which explains the O(N 2 ) time complexity for the evaluation of Q.) An eager evaluation does just this: It readily computes the list of tuples in the query result of Q. This requires quadratic preprocessing time, after which the tuples in the query result can be enumerated with constant delay [OZ12].
In contrast, a lazy evaluation approach computes the first tuple in the query result then the second tuple and so on. This can be done using linear preprocessing time followed by linear enumeration delay for each tuple in the result [BDG07]. It is conjectured that the delay cannot be lowered to constant after linear-time preprocessing for Q [BDG07]. (The explanation is that Q is not free-connex, a notion we will introduce in Section 4.) Our approach achieves O(N 1+ϵ ) preprocessing time and O(N 1−ϵ ) enumeration delay for any ϵ ∈ [0, 1]. The complexities of the eager, lazy, and our approach are as follows: Our approach recovers the lazy approach at ϵ = 0 and the eager approach at ϵ = 1. For any ϵ ∈ (0, 1), it achieves new trade-offs between preprocessing time and enumeration delay.
Given that the input relations have size N , the AGM bound [AGM13] implies that the result of the query has at most N 2 tuples. Assume that we want to enumerate N γ tuples from the result, for some 0 ≤ γ ≤ 2. In the following table, the second to fourth rows give the exponents of the overall evaluation times achieved by the lazy, eager, and our approaches for different values of γ. The last row gives the ϵ values at which we achieve the complexities of our approach. 1 For instance, if γ = 1 1 2 , the lazy approach requires O(N + N 1+ 1 2 · N ) = O(N 2+ 1 2 ), the eager approach requires O(N 2 + N 1+ 1 2 · 1) = O(N 2 ), and our approach needs only O(N 1+ 3 4 + N 1+ 1 2 N 1 4 ) = O(N 1+ 3 4 ) time at ϵ = 3 4 . In case γ is equal to 1 2 , 1, or 1 1 2 , the overall computation time of our approach (highlighted in green) is strictly lower than the eager and lazy approaches. For the other two cases shown in the table, our approach recovers the lower complexity of the prior approaches (highlighted in yellow).
2.1. Further Prior Work on Static Query Evaluation. We complement our discussion with further prior work on static query evaluation. Figure 3 gives a taxonomy of works in this area.
Prior work exhibits a dependency between the space and enumeration delay for conjunctive queries with access patterns [DK18]. It constructs a succinct representation of the query result that allows for enumeration of tuples over some variables under value bindings for all other variables. It does not support enumeration for queries with projection, as addressed in our work. It also states Example 9.1 as an open problem.
The result of any α-acyclic conjunctive query can be enumerated with constant delay after linear-time preprocessing if and only if it is free-connex. This is under the conjecture that Boolean multiplication of n × n matrices cannot be done in O(n 2 ) time [BDG07]. More recently, this was shown to hold also under the hypothesis that the existence of a triangle in

Class of Queries
Preprocessing Delay Extra Space Source CQ on X-structures (trees, grids) a hypergraph of n vertices cannot be tested in time O(n 2 ) and that for any k, testing the presence of a k-dimensional tetrahedron cannot be decided in linear time [BB13]. The freeconnex characterization generalizes in the presence of functional dependencies [CK18]. An in-depth pre-2015 overview on constant-delay enumeration is provided by Segoufin [Seg15]. There are also enumeration algorithms for document spanners [ABMN19] and satisfying valuations of circuits [ABJM17].

Trade-offs in Dynamic Query Evaluation
Our main result for the dynamic query evaluation generalizes the static case.
Theorem 3.1. Given a hierarchical query with static width w and dynamic width δ, a database of size N , and ϵ ∈ [0, 1], the query result can be enumerated with O(N 1−ϵ ) delay after O(N 1+(w−1)ϵ ) preprocessing time and O(N δϵ ) amortized update time for single-tuple updates.
The left plot in Figure 1 depicts the preprocessing time (dotted green line), the update time (dashed red lines), and the enumeration delay (purple line) of our approach in the dynamic case. For hierarchical queries, the dynamic width δ can be equal to either the static width w or w − 1 (Proposition 4.8). The plot hence shows two dashed red lines for the update time. The right plot in Figure 1 depicts the trade-off between the three components. Our approach can achieve sublinear amortized update time and delay for hierarchical queries with arbitrary free variables ( Figure 1 left and right). For any ϵ = 1 δ+α > 0 with α > 0, our algorithm has update time O(N 1−α· 1 δ+α ) and delay O(N 1− 1 δ+α ).
The update time for a single tuple is at most the preprocessing time: δϵ ≤ wϵ ≤ ϵ + (w − 1)ϵ ≤ 1 + (w − 1)ϵ. If δ = w − 1, then δϵ = (w − 1)ϵ, i.e., the update time is an O(N ) factor less than the preprocessing time. The complexity of preprocessing thus amounts to inserting N tuples in an initially empty database using our update mechanism. If δ = w, then inserting N tuples would need O(N 1+(w−1)ϵ+ϵ ) time, which is an O(N ϵ ) factor more than the complexity of one bulk update using our preprocessing algorithm. This suggests a gap between single-tuple updates and bulk updates. A similar gap highlighting a fundamental limitation of single-tuple updates has been shown for the Loomis-Whitney query that generalizes the triangle query from a join of three binary relations to a join of n (n − 1)-ary relations: The amortized update time for single-tuple updates is O(N 1/2 ), which is worst-case optimal unless the Online Matrix-Vector Multiplication conjecture fails [KNN + 19b]. Inserting N tuples in the empty database would cost O(N 3/2 ), yet the query can be computed in the static setting in time O(N n n−1 ) [NPRR18]. Amortized O(N δϵ ) update time means that, given any sequence of updates, the average cost of a single update is O(N δϵ ). Since updates can change the data structure, our approach needs to do a rebalancing step whenever the data structure gets out of balance. The time needed for a single update without rebalancing is O(N δϵ ) in the worst case. A rebalancing step can require super-linear time (Propositions 7.3 and 7.4). We show that for any update sequence, the overall time needed for the updates and rebalancing steps, when averaged over the number of updates in the sequence, remains O(N δϵ ) in the worst case (Proposition 7.5). Using classical de-amortization techniques [KP98], we can adapt our update mechanism to obtain non-amortized O(N δϵ ) update time. The de-amortization strategy is analogous to the one used for the update mechanism of triangle queries (Section 10 in [KNN + 20]), which performs more frequent but less time-consuming rebalancing steps.
Theorem 3.1 recovers prior work on conjunctive queries [NO18], free-connex acyclic queries [IUV17], and q-hierarchical queries [BKS17a] by setting ϵ = 1 (Figure 1 right). For hierarchical queries in general, our approach achieves the same complexities as prior work on conjunctive queries when restricted to hierarchical queries. For free-connex queries, we obtain linear-time preprocessing and update and constant-time delay since w = 1 (Proposition 4.9) and then δ ∈ {0, 1} (Proposition 4.8) for these queries. For q-hierarchical queries, we obtain linear-time preprocessing and constant-time update and delay since w = 1 and δ = 0. Existing maintenance approaches, e.g, classical first-order IVM [CY12] and higher-order recursive IVM [K + 14], DynYannakakis [IUV17], and F-IVM [NO18], can achieve constant delay for general hierarchical queries yet after at least linear-time updates. The right Venn diagram in Figure 2 relates Theorem 3.1 with prior results.
The next example illustrates that our approach achieves better overall evaluation time than existing approaches when considering a sequence of updates. The query has static and dynamic width 1. We assume that the input relations are of size N and consider the dynamic setting.
A lazy evaluation approach requires no preprocessing: For each single-tuple update, it only updates the input relations without propagating the changes to the query result. Before enumerating the A-values in the query result, it first scans the relation R to collect all A-values that are paired with B-values contained in S. This takes linear time. Afterwards, the approach can enumerate the A-values with constant delay.
An eager evaluation approach precomputes the initial result in linear time. On a singletuple update, it computes the delta query obtained by fixing the variables of one relation to constants. For an update δR(a, b) to R, the delta query δQ(a) = δR(a, b), S(b) can be computed in constant time. For an update δS(b) to S, the delta query δQ(A) = R(A, b), δS(b) can be computed in linear time. In general, the update time is linear. Since the query result is materialized and eagerly maintained, the A-values in the result can be enumerated after an update with constant delay.
For this query, our approach achieves O(N ) preprocessing time, O(N ϵ ) update time, and O(N 1−ϵ ) enumeration delay for any ϵ ∈ [0, 1]. The following table summarizes the preprocessing-update-delay trade-off achieved by the three approaches: Our approach recovers the lazy and eager approaches by setting ϵ to 0 and respectively 1, with one exception: it cannot recover the constant preprocessing time in the lazy approach as it requires one pass over the input data.
Consider now a sequence of N m updates, each followed by one access request to enumerate N γ values out of the at most N A-values in the query result, for m, γ ∈ [0, 1]. With the eager and lazy approaches, this sequence takes time (excluding preprocessing) O(N m (N + N γ )), which is O(N m+1 ) since γ ≤ 1. With our approach, the sequence takes O(N m (N ϵ + N γ N 1−ϵ )) = O(N m+ϵ + N m+γ+1−ϵ ). Depending on the values of m and γ, we can tune our approach (by appropriately setting ϵ) to minimize the overall time to execute the bulk of updates and access requests. For γ < 1 and any m, our approach has consistently lower complexity than the lazy/eager approaches, while for γ = 1 and any m it matches that of the lazy/eager approaches. The complexity of processing the sequence of updates and access requests is shown in the next table for various values of m and γ: The middle five columns (highlighted by green and yellow) show the complexities for our approach. The last row states the values of ϵ for which the complexities in the same columns are obtained. The rightmost five columns show the complexities for the lazy/eager approaches for γ ∈ {0, 1 4 , 1 2 , 3 4 }. They are all higher than for our approach, except for the last column for which γ = 1: Regardless of m, the complexity gap is O(N Class of Queries Preprocessing Update Delay Extra Space Source 3.1. Further Prior Work on Dynamic Query Evaluation. We discuss further prior work on dynamic query evaluation. Figure 4 gives a taxonomy of works in this field. The q-hierarchical queries are the conjunctive queries that admit linear-time preprocessing and constant-time update and delay [BKS17a,IUV17]. If a conjunctive query without repeating relation symbols is not q-hierarchical, there is no γ > 0 such that the query result can be enumerated with O(N 1 2 −γ ) delay and update time, unless the Online Matrix Vector Multiplication conjecture fails. The constant delay and update time carry over to first-order queries with modulo-counting quantifiers on bounded degree databases, unions of q-hierarchical queries [BKS18], and q-hierarchical queries with small domain constraints [BKS17b].
Prior work characterizes the preprocessing-space-update trade-off for counting triangles under updates [KNN + 19a]. A follow-up work generalizes this approach to the triangle queries with arbitrary free variables, adding the enumeration delay to the trade-off space [KNN + 20]. In this work, we consider arbitrary hierarchical queries instead of the triangle queries, and we use a less trivial adaptive maintenance technique, where the same relation may be subject to partition on different tuples of variables and where the overall number of cases for each partition is reduced to only two: the all-light case and the at-least-one-heavy case.
MSO queries on strings admit linear-time preprocessing, constant delay, and logarithmic update time. Here, updates can relabel, insert, or remove positions in the string. Further work considers MSO queries on trees under updates [LM14,ABM18].

Preliminaries
Data Model. A schema X = (X 1 , . . . , X n ) is a non-empty tuple of distinct variables. Each variable X i has a discrete domain Dom(X i ). We treat schemas and sets of variables interchangeably, assuming a fixed ordering of variables. A tuple x of data values over schema X is an element from Dom(X ) = Dom(X 1 ) × · · · × Dom(X n ).
A relation R over schema X is a function R : Dom(X ) → Z such that the multiplicity R(x) is non-zero for finitely many tuples x. A tuple x is in R, denoted by x ∈ R, if R(x) ̸ = 0. The notation ∃R denotes the use of R with set semantics: ∃R(x) equals 1 if x ∈ R and 0 otherwise; also, ∄R(x) = 1 − ∃R(x). The size |R| of R is the size of the set {x | x ∈ R}. A database is a set of relations and has size given by the sum of the sizes of its relations.
Given a tuple x over schema X and S ⊆ X , Computational Model. We consider the RAM model of computation where schemas and data values are of constant size. We assume that each relation R over schema X is implemented by a data structure that stores key-value entries (x, R(x)) for each tuple x with R(x) ̸ = 0 and needs O(|R|) space. This data structure can: (1) look up, insert, and delete entries in constant time, (2) enumerate all stored entries in R with constant delay, and (3) report |R| in constant time. For a schema S ⊂ X , we use an index data structure that for any t ∈ Dom(S) can: (4) enumerate all tuples in σ S=t R with constant delay, (5) check t ∈ π S R in constant time; (6) return |σ S=t R| in constant time; and (7) insert and delete index entries in constant time.
In an idealized setting, the above requirements can be ensured using hashing. In practice, hashing can only achieve amortized constant time for some of the above operations. In our paper, whenever we claim constant time for hash operations, we mean amortized constant time. We give a hash-based example data structure that supports the above operations in amortized constant time. Consider a relation R over schema X . A hash table with chaining stores key-value entries (x, R(x)) for each tuple x over X with R(x) ̸ = 0. The entries are doubly linked to support enumeration with constant delay. The hash table can report the number of its entries in constant time and supports lookups, inserts, and deletes in amortized constant time. To support index operations on a schema F ⊂ X , we create another hash table with chaining where each table entry stores an F-value t as key and a doubly-linked list of pointers to the entries in R having t as F-value. Looking up an index entry given t takes amortized constant time, and its doubly-linked list enables enumeration of the matching entries in R with constant delay. Inserting an index entry into the hash table additionally prepends a new pointer to the doubly-linked list for a given t; overall, this operation takes amortized constant time. For efficient deletion of index entries, each entry in R also stores back-pointers to its index entries (one back-pointer per index for R). When an entry is deleted from R, locating and deleting its index entries in doubly-linked lists takes constant time per index. An alternative data structure that can meet our requirements is a tree-structured index such as a B + -tree. This would, however, require worst-case logarithmic time and imply an additional logarithmic factor in our complexity results.
Modeling Updates Using Multiplicities. We restrict multiplicities of tuples in the input relations to be strictly positive. Multiplicity 0 means the tuple is not present. A single-tuple update to a relation R is expressed as δR = {x → m}. The update is an insert of the tuple x in R if the multiplicity m is strictly positive. It is a delete of x from R if m is negative. Such a delete is rejected if the existing multiplicity of x in R is less than |m|. A batch update may consist of both inserts and deletes. Applying δR to R means creating a new version of R that is the union of δR and R.
Partitioning. The number of occurrences of a value in a relation is called the degree of the value in the relation. We partition relations based on value degree.
Definition 4.1. Given a relation R over schema X , a schema S ⊂ X , and a threshold θ, the pair (H, L) of relations is a partition of R on S with threshold θ if it satisfies the following four conditions: (strict heavy part) for all t ∈ π S H : |σ S=t H| ≥ θ (strict light part) for all t ∈ π S L : |σ S=t L| < θ The relations H and L are the heavy and light parts of R.

Queries. A conjunctive query (CQ) has the form
We denote by: (R i ) i∈[n] the relation symbols; (R i (X i )) i∈[n] the atoms; vars(Q) = i∈[n] X i the set of variables; free(Q) = F ⊆ vars(Q) the set of free variables; bound (Q) = vars(Q) − free(Q) the set of bound variables; atoms(Q) = {R i (X i ) | i ∈ [n]} the set of the atoms; and atoms(X) the set of the atoms containing X. The query Q is full if free(Q) = vars(Q).
The hypergraph G = (vars(Q), atoms(Q)) of a query Q has one node per variable and one hyperedge per atom that covers all nodes representing its variables. A join tree for Q is a tree with the following properties: (1) Its nodes are exactly the atoms of Q; (2) if any two nodes have variables in common, then all nodes along the path between them also have these variables. The query Q is called α-acyclic if it has a join tree. It is free-connex if it is α-acyclic and remains α-acyclic when we add to its body a fresh atom over its free variables [BB13]. It is hierarchical if for any two of its variables, either their sets of atoms are disjoint or one is contained in the other. It is q-hierarchical if it is hierarchical and for every variable A ∈ free(Q), if there is a variable B such that atoms(A) ⊂ atoms(B) then B ∈ free(Q) [BKS17a].   It is also hierarchical but not q-hierarchical: The bound variables B and E dominate the free variables C and respectively F .
Variable Orders. Two variables depend on each other if they occur in the same atom.
Definition 4.3 (adapted from [OZ15]). A variable order ω for a conjunctive query Q is a pair (T, dep ω ) such that the following holds: • T is a rooted forest with one node per variable in Q. The variables of each atom in Q lie along the same root-to-leaf path in T . • The function dep ω maps each variable X to the subset of its ancestor variables in T on which the variables in the subtree rooted at X depend, i.e., for every variable Y that is a child of variable An extended variable order is a variable order where we add as new leaves the atoms corresponding to relations. We add each atom as the child of its variable placed lowest in the variable order. Whenever we refer to a variable order, we mean its extension with atoms at leaves. For ease of presentation, we often use ω to refer to the tree of ω.
The subtree of a variable order ω rooted at X is denoted by ω X . The sets vars(ω), atoms(ω), and anc(X) consist of all variables of ω, the atoms at the leaves of ω, and the variables on the path from X to the root excluding X, respectively. The flag has sibling(X) is true if X has siblings. The variable order ω is free-top if no bound variable is an ancestor of a free variable (called d-tree extension [OZ15]). It is canonical if the variables of the leaf atom of each root-to-leaf path are the inner nodes of the path. The sets freeTopVO(Q), canonVO(Q), and VO(Q) consist of free-top, canonical, and all variable orders of Q.
Example 4.4. The left variable order in Figure 5 is a canonical variable order for the query from Example 4.2. This variable order is not free-top since the bound variables B and E sit on top of the free variables C and respectively F . The right variable order in Figure 5 is a free-top variable order for the query. This variable order is not canonical: the atom at the leaf of the path A − C − B − D − S(ABD) does not have the variable C.
Hierarchical queries admit canonical variable orders, while q-hierarchical queries admit canonical free-top variable orders. The canonical variable order of a hierarchical query is unique up to orderings of variables sharing the same set of atoms.
Width Measures. Given a conjunctive query Q and F ⊆ vars(Q), a fractional edge cover of F is a solution λ = (λ R(X ) ) R(X )∈atoms(Q) to the following linear program [AGM13]: The optimal objective value of the above program is called the fractional edge cover number of the variable set F and is denoted as ρ * Q (F). An integral edge cover of F is a feasible solution to the variant of the above program with λ R(X ) ∈ {0, 1} for each R(X ) ∈ atoms(Q). The optimal objective value of this program is called the integral edge cover number of F and is denoted as ρ Q (F). If Q is clear from the context, we omit the index Q in the expressions ρ * Q (F) and ρ Q (F). For a database of size N , the result of the query Q can be computed in time O(N ρ * ) [NPRR18].
For hierarchical queries, the integral and fractional edge cover numbers are equal. The proofs of the following propositions in this section are given in the technical report [KNOZ19] (Appendices B and C). Definition 4.6. The static width of a conjunctive query Q is If Q is Boolean, then w is the fractional hypertree width [Mar10]. FAQ-width generalizes w to queries over several semirings [AKNR16] 1 .
Definition 4.7. The dynamic width of a conjunctive query Q is While the static width of a free-top variable order ω is defined over the sets {X}∪dep ω (X) with X ∈ vars(Q), the dynamic width of ω is defined over restrictions of these sets obtained by dropping the variables in the schema of one atom. For any canonical variable order ω, variable X in ω, and atom R(Y) in atoms(ω X ), the set ({X} ∪ dep ω (X)) − Y is empty. Hence, queries that admit canonical free-top variable orders have dynamic width 0.
Proposition 4.8. Given a hierarchical query with static width w and dynamic width δ, it holds that δ = w or δ = w − 1.
Free-connex hierarchical queries have static width 1.
1 To simplify presentation, we focus on queries that contain at least one atom with non-empty schema.
This implies that the static width of queries is at least 1. Queries where all atoms have empty schemas obviously admit constant preprocessing time, update time, and enumeration delay. Proposition 4.9. Any free-connex hierarchical query has static width 1.
We give a syntactic classification of hierarchical queries based on their dynamic width.
The class of hierarchical queries can be partitioned into subclasses of δ ihierarchical queries for i ∈ N. Then, the δ 0 -hierarchical queries are precisely the q-hierarchical queries from prior work [BKS17a].
Proposition 4.11. A query is q-hierarchical if and only if it is δ 0 -hierarchical. Figure 2 (right), all free-connex hierarchical queries are either δ 0 -or δ 1 -hierarchical.
The following proposition relates δ i -hierarchical queries to their dynamic width.

Preprocessing
In the preprocessing stage, we construct a data structure that represents the result of a given hierarchical query. The data structure consists of a set of view trees, where each view tree computes one part of the query result. A view tree is a tree-shaped hierarchy of materialized views with input relations as leaves and upper views defined in terms of their child views. The construction of view trees exploits the structure of the query and the degree of data values in base relations. We construct different sets of view trees for the static and dynamic evaluation of a given hierarchical query.
We next assume that the canonical variable order of the given hierarchical query consists of a single connected component. For several connected components, the preprocessing procedure is executed on each connected component separately. 5.1. View Trees Encoding the Query Result. Given a hierarchical query Q(F) and a canonical variable order ω for Q, the function BuildVT in Figure 6 constructs a view tree that encodes the query result. The function proceeds recursively on the structure of ω and constructs a view over schema F X at each inner node X; the leaves correspond to the atoms in the query. The view is defined over the join of its child views projected onto F X (Figure 7). The schema F X includes the ancestors of X in ω since they are needed for joins at nodes above X. Each constructed view has a name to help us identify the place and purpose of the view in the view tree.
BuildVT(string prefix , variable order ω, schema F) : view tree switch ω: return NewVT(viewname, F X , subtrees) . Construction of a view tree for a canonical variable order ω of a hierarchical query with free variables F. View names share a given prefix .
NewVT(string viewname, schema S, view trees T 1 , . . . , T k ) : view tree If X is free, then it is included in the schema of the view constructed at X (and not included if bound). It is also kept in the schemas of the views on the path to the root until it reaches a view whose schema does not have bound variables. The constructed view tree has the upper levels only with views over the free variables. The hierarchy of such views represents the query result and allows its enumeration with constant delay.
In the dynamic case, at each child Z of X we construct a view with schema anc(Z) on top of the view created at Z (Figure 8). This auxiliary view aggregates away Z from the latter view. The children of the view created at X then share the same schema F X . This property enables the efficient maintenance of the view at X since processing a change coming from any child view requires only constant-time lookups into that child's sibling views.
Our preprocessing is particularly efficient for free-connex hierarchical queries in the static case and for their strict subclass of δ 0 -hierarchical queries in the dynamic case.
For a canonical variable order of a hierarchical query, the free-connex property fails if there are free variables such that they are below a bound join variable and are not covered AuxView(node Z, view tree T ) : view tree This creates a cycle in the hypergraph of Q, which means that Q is not free-connex. For δ 0 -hierarchical queries, there is no bound variable whose set of atoms strictly contains the atoms of a free variable. Such queries thus admit canonical free-top variable orders where all free variables occur above the bound ones.
For any free-connex hierarchical query, each view created by BuildVT is defined over variables from one atom of the query and can be materialized in linear time. We can thus recover the linear-time preprocessing for such queries used for static [BDG07] and dynamic [BKS17a,IUV17] evaluation. and its canonical variable order in Figure 9. We construct the view tree bottom-up as follows. At C, we create the view V C (A, B) that aggregates away the bound variable C but keeps its ancestors A and B to define views up in the tree. Since D is free and has only one child, we skip creating a view at D; see the first case in Line 4 of NewVT from 5.2. Skew-Aware View Trees. For free-connex queries, the procedure BuildVT constructs in linear time a data structure that allows for constant-time enumeration delay (Proposition 6.1 and Lemma C.4). For δ 0 -hierarchical queries, it also admits constant-time updates (Lemma E.1). We now focus on the bound join variables that violate the free-connex property in the static case or the δ 0 -hierarchical property in the dynamic case. For each such violating bound variable X, we use two evaluation strategies.
The first strategy materializes a subset of the query result obtained for the light values over the set of variables anc(X) ∪ {X} in the variable order. It also aggregates away the bound variables in the subtree rooted at X. Since the light values have a bounded degree, this materialization is inexpensive. The second strategy computes a compact representation of the rest of the query result obtained for those values over anc(X) ∪ {X} that are heavy (i.e., have high degree) in at least one relation. This second strategy treats X as a free variable and proceeds recursively to resolve further bound variables located below X in the variable order and to potentially fork into more strategies.

Vol. 19:3 TRADE-OFFS IN STATIC AND DYNAMIC EVALUATION OF HIERARCHICAL QUERIES 11:17
The union of these strategies precisely cover the entire query result, yet not necessarily disjointly. To enumerate the distinct tuples in the query result, we then use an adaptation of the union algorithm [DS11] where the delay is given by the number of heavy values of the variables we partitioned on and by the number of strategies.
Heavy and Light Indicators. We consider a bound join variables that violates the freeconnex property in the static case or the δ 0 -hierarchical property in the dynamic case. We compute heavy and light indicator views consisting of disjoint sets of values for each such variable X. The heavy indicator has the values that exist in all relations and are heavy in at least one relation. The light indicator has the values that exist in all relations and are light in all relations. Indicator views have set semantics. They allow us to rewrite the query into an equivalent union of two queries.
Partitioning the query result only based on the degree of X-values may blow up the enumeration delay: the path from X to the root may contain several bound join variables, each creating buckets of values per bucket of their ancestors, thus leading to an explosion of the number of buckets that need to be unioned together during enumeration. However, one remarkable property holds for hierarchical queries: each base relation located in the subtree rooted at X contains X but also all the ancestors of X. Thus, by partitioning each relation jointly on X and its ancestors, we can ensure the enumeration delay remains linear in the number of distinct heavy values over anc(X) ∪ {X}. Figure 10 shows how to construct a triple of view trees for computing the indicators for anc(X) ∪ {X}, where X is the root of a variable order ω that is a subtree in the variable order of a hierarchical query (thus anc(X) may be non-empty). We first construct a view tree that computes the tuples of values for variables keys = anc(X) ∪ {X} over the join of the relations from ω. We then build a similar view tree for the light indicator for keys using a modified variable order ω keys of the same structure as ω but with each relation R replaced by the light part of R partitioned on keys. Finally, the view tree for the heavy indicator computes the difference of all keys-values and those from the light indicator.
View Trees with Indicators. Figure 11 gives the algorithm for constructing the view trees for a variable order ω of a hierarchical query Q(F). The algorithm traverses the variable order ω top-down, maintaining the invariant that all ancestors of a node are free variables (or treated as such in case of bound join variables whose values are heavy).
The free variables at node X are the ancestors of X and the free variables in the subtree rooted at X (Line 3). If the residual query Q X at node X (Line 4) is free-connex in the static case or δ 0 -hierarchical in the dynamic case, we return a view tree for Q X (Lines 5-7). If X is free, we recursively compute a set of view trees for each child of X. We may extend the root of each child tree with an auxiliary view in the dynamic mode to support constant-time propagation of updates coming via the siblings of X. For each combination of the child view trees, we form a new view joining the roots of the child view trees and using X and its ancestors as free variables (Lines 8-11). If X is bound, we create two evaluation strategies for the residual query Q X based on the degree of values of X and its ancestors in the relations of Q X . We construct the indicator view trees for X and its ancestors (Line 12). The heavy indicator restricts the joins of the child views to only heavy values for the tuple of X and its ancestors (Lines 13-15). We also construct a view tree over the light parts of the relations in ω (Line 16).
The algorithm from Figure 11 uses different criteria for the static and dynamic cases (Lines 5-6) to decide on whether to stop recursively traversing the variable order. Since the class of δ 0 -hierarchical queries is a proper subset of the class of free-connex queries, the algorithm may partition input relations on more attributes and create more view trees in the dynamic case than in the static case for the same variable order and free variables.
We next showcase our approach on a non-free-connex query. Section 9 provides additional examples with δ 1 -hierarchical queries.
Example 5.2. Figure 12 shows the view trees for the query We start from the root A in the variable order. Since Q is not free-connex (and also not δ 0 -hierarchical) and A is bound, we create the view trees for the indicators H A (A) and L A (A). Materializing the views in these view trees takes linear time.
τ (variable order ω, free variables F) : set of view trees switch ω:  Given a hierarchical query, our algorithm effectively rewrites it into an equivalent union of queries, with one query defined by the join of the leaves of a view tree.
Proposition 5.3. Let {T 1 , . . . , T k } = τ (ω, F) be the set of view trees constructed by the algorithm in Figure 11 for a given hierarchical query Q(F) and a canonical variable order ω for Q. Let Q (i) (F) be the query defined by the conjunction of the leaf atoms in T i , ∀i ∈ [k].
The preprocessing time of our approach is given by the time to materialize the views in the view trees.

Enumeration
For any hierarchical query, Section 5 constructs a set of view trees that together represent the query result. We now show how to enumerate the distinct tuples in the query result with their multiplicity using the open/next/close iterator model for such view trees. Each view in a view tree follows the iterator model. The function V.open(ctx) initializes the iterator on view V using the tuple ctx as context, setting the range of the iterator to those tuples that are consistent with ctx in V , that is, ctx is part of each such tuple in V . The function V.next() returns a tuple consistent with ctx in V ; or it returns EOF if the tuples in the range of the iterator are exhausted. The tuples returned by V.next() are distinct. Both functions operate in constant time, as per our computational model.
Given a subtree T of a view tree and the current tuple ctx in its parent view, the call T .open(ctx ) described in Figure 13 sets the range of the iterator of T to those tuples in its root view that agree with ctx and positions the iterator at the first tuple in this range. The open call is recursively propagated down the view tree with an increasingly more specific context tuple. A T.close() call resets the iterators of tree T . Each subtree T has an attribute T.tuple storing the next tuple to be reported. The open method ends with a call to T.next() to set T.tuple to the first tuple to be reported.
There are two cases that need special attention. If the schema of a view V includes all free variables in the subtree rooted at V , then there is no need to open the views in this subtree since V already has the tuples over these free variables; e.g., this is the case of the  Figure 12, also require special treatment. If V has as child a heavy indicator ∃H, the tree T rooted at V represents possibly overlapping relations in the contexts given by the different tuples h ∈ ∃H. We ground the heavy indicator by creating an iterator for each heavy tuple agreeing with the current tuple ctx at the parent view of V and keep this iterator in a shallow copy of T . Creating a shallow copy of T means creating a tree of iterators of the same structure as T but without copying the content of views under T .
After the first open call for a view tree T , we can enumerate the distinct tuples from T with their multiplicity by calling T.next(), see Figure 14. The next call propagates recursively down T and observes the same cases as the open call. If a view V in T already covers all free variables in T , then it suffices to enumerate from V . If T has as child a heavy indicator, we return the next tuple and its multiplicity from the union of all its groundings using the Union algorithm (Section 6.1). Otherwise, we synthesize the returning tuple out of the tuples at the iterators of T 's children. Given the current context at T 's view, we return the next tuple and its multiplicity from the Cartesian product of the tuples produced by T 's children using the Product algorithm (Section 6.2).
For a view tree with no heavy indicators, calling open and next on the view tree translates to calling open and next on its views, where each such call on a view takes constant time and the number of such calls is independent of the size of the database. Thus, calling open and next on a view tree with no heavy indicators takes constant time.
In the presence of heavy indicators, the time to initialize a view tree and produce the next tuple is dominated by the number of shallow view trees created in the grounding step. The delay of the Union algorithm is the sum of the delays of the grounded view trees. Their number is determined by the size of the heavy indicators in the view tree, which is O (N 1−ϵ ).
Thus, calling open and next on a view tree with heavy indicators takes O(N 1−ϵ ) time.
So far we discussed the case of enumerating from one view tree. In case of a set of view trees we again use the Union algorithm. In case the query has several connected components, i.e., it is a Cartesian product of hierarchical queries, we use the Product algorithm with an empty context.
The multiplicity for a tuple returned by the Union algorithm is the sum of the multiplicities of its occurrences across the buckets, while for a tuple returned by the Product algorithm it is the multiplication of the multiplicities of the constituent tuples. Since all tuples in the database have positive multiplicities, the derived multiplicities are always strictly positive and therefore the returned tuple is part of the result.
We next explain the Union and Product algorithms used by T.next() in Figure 14.
6.1. The Union Algorithm. The Union algorithm is given in Figure 15. It is an adaptation of prior work [DS11]. It takes as input n view trees that represent possibly overlapping sets of tuples over the same relation and returns a tuple and its multiplicity in the union of these sets, where the tuple is distinct from all tuples returned before. We first explain the algorithm on two views T 1 and T 2 that have been already open and with their iterators positioned at the first respective tuples. On each call, we return one tuple together with its multiplicity or EOF. We check whether the next tuple t 1 in T 1 is also present in T 2 . If so, we return the next tuple in T 2 and its total multiplicity from T 1 and T 2 ; otherwise, we return t 1 and its multiplicity in T 1 . If T 1 is exhausted, we return the next tuple in T 2 and its total multiplicity from T 1 and T 2 , or EOF if T 2 is also exhausted.
In case of n > 2 views, we consider one view defined by the union of the first n − 1 views and a second view defined by T n , and we then reduce the general case to the previous case of two views.
The delay of this algorithm is given by the delay of iterating over each view, the cost of lookups into the views, and the cost of computing output multiplicities. The lookup costs are constant when using a hierarchy of materialized views for representing the query result [OZ15]. Given n views, computing an output multiplicity takes O(n) time. The overall delay is the sum of the delays of the n views, which is O(n).
In our paper, we employ the Union algorithm in two cases: (1) on the set of view trees obtained after grounding the heavy indicators; and (2) on the set of view trees obtained by using skew-aware indicators in the preprocessing stage. In the first case, the number of the Product(view trees T 1 , . . . , T k , tuple ctx ) : tuple 6.2. The Product Algorithm. The Product algorithm is given in Figure 16. It takes as input a set of view trees T 1 , . . . , T k and a context, which is the current tuple in the parent view, and outputs the next tuple and its multiplicity in the Cartesian product of the tuples returned by the k view trees given the context. By construction, the parent view joins the roots of the k view trees and thus yields only contexts for which each of the view trees produces a non-empty result.
In case k = 1, we execute the innermost loop for T k : On a call, we take the current tuple in T k and project away the variables that are in common with the context tuple, retaining only the free variables in T k . We concatenate this projection with the context tuple. The concatenation operator is •. Before we return this concatenated tuple and its multiplicity, we advance the iterator to the next tuple-multiplicity pair in T k . Eventually, we reach the end of the iterator for T k , in which case we return EOF.
In case k > 1, we hold the current tuple-multiplicity pairs for T 1 , . . . , T k−1 and iterate over T k . Whenever T k reaches EOF, we reset it and advance the iterator for T k−1 . We concatenate the context tuple and the current tuples of all iterators, projected onto the variables that are not in the schema of the context tuple (since those fields are already in the context). We multiply the current multiplicities of all iterators and advance the iterator for T k before returning the concatenated tuple and its multiplicity.
The delay for a Product call is given by the sum of the delays of the k input view trees. In the worst case, the algorithms makes k − 1 open calls and k next calls before returning the next tuple. We use this algorithm in two cases: (1) enumerating from a view with several children in a tree (in which case the context is given as the current tuple in the view); (2) a collection of view trees, one per connected component of the input query (in which case the context is the empty tuple). In both cases, the number of parameters to the Product call is independent of the size of the database and only dependent on the number of atoms and respectively of connected components in the input query. This means that the delay (in data complexity) is the maximum delay of any of its parameter view trees, which is O (N 1−ϵ ).
We next state the complexity of enumeration in our approach.
Proposition 6.1. The tuples in the result of a hierarchical query Q(F) over a database of size N can be enumerated with O(N 1−ϵ ) delay using the view trees constructed by τ (ω, F) for a canonical variable order ω for Q.

Updates
We present our strategy for maintaining the views in the set of view trees τ (ω, F) constructed for a canonical variable order ω of a hierarchical query Q(F) under updates to input relations. We specify here the procedure for processing a single-tuple update to any input relation. Processing a sequence of such updates builds upon this procedure and occasional rebalancing steps (Section 7.2). We write δR = {x → m} to denote a single-tuple update δR mapping the tuple x to the non-zero multiplicity m ∈ Z and any other tuple to 0; i.e., |δR| = 1. Inserts and deletes are updates represented as relations in which tuples have positive and negative multiplicities. We assume that after applying an update to the database, all relations and views contain no tuples with negative multiplicities.
Compared to static evaluation, our strategy for dynamic evaluation may construct additional views to support efficient updates to all input relations. In Figure 12, the view tree created for the case of heavy (A, B)-values (second row right) has five such additional views, marked with dashed boxes. These views enable an update to any leaf view to be propagated to the root view in constant time. For instance, the views R ′ and S ′ eliminate the need to iterate over the D-values in relation R for updates to relation S and ∃H B and respectively over the E-values in S for updates to R and ∃H B . Figure 8 gives the rule for creating such views: If node Z has a sibling in the variable order, then we create an auxiliary view that aggregates away Z to avoid iterating over the Z-values for updates coming via the (auxiliary) views constructed for the siblings of Z.

Processing a Single-Tuple
Update. An update δR to a relation R may affect multiple view trees in the set of view trees constructed by our algorithm from Figure 11. 2 We apply δR to each such view tree in sequence, by propagating changes along the path from the leaf R to the root of the view tree. For each view on this path, we update the view result with the change computed using the standard delta rules [CY12] (see Example 9.1).
To simplify the reasoning about the maintenance task, we assume that each view tree has a 2 We focus here on updates to hierarchical queries without repeating relation symbols. In case a relation R occurs several times in a query, we treat an update to R as a sequence of updates to each occurrence of R.

11:26
A. Kara Apply(view tree T , update δR) : delta view switch T : copy of its base relations. We use Apply(T, δR) from Figure 17 to propagate an update δR in a view tree T ; if T does not refer to R, the procedure has no effect.
Updates to indicator views, however, may trigger further changes in the views constructed over them. Consider, for instance, the heavy indicator H B (A, B) constructed over the view  Figure 18 shows the function UpdateIndTree that applies an update δR to an indicator tree T Ind with a root view I(S). The function returns the change δ(∃I) in the support of the indicator view I, to be further propagated to other views. The free variables S of I appear in each input relation from T Ind , and δR fixes their values to constants; thus, |δ(∃I)| ≤ 1.

Vol. 19:3 TRADE-OFFS IN STATIC AND DYNAMIC EVALUATION OF HIERARCHICAL QUERIES 11:27
UpdateTrees(view trees T , indicator triples T Ind , update δR)  gives our algorithm for maintaining a set of view trees T and a set of indicator tress T Ind under an update δR. We first apply δR to the view trees from T (Line 1). Then, we consider the triples (T All , T L , T H ) of indicator trees from T Ind that are affected by δR. We maintain the heavy indicator tree T H with the root H(S) = All(S), ∄L(S) for changes in both All and ∄L. We apply δR to T All (Line 6) and subsequently δAll to T H (Line 8). The latter may trigger a change δ(∃H) in the support of H, which we apply to the view trees from T (Line 9). If the update δR belongs to the light part R S (Line 10), we apply δR S to the view trees from T and to the light indicator tree T L (Lines 11-12). We then propagate the opposite change δ(∄L) in the support of the root L of T L , if any, to T H and further to the view trees from T (Lines 13-14).
Example 7.1. We analyze the time needed to maintain the views from Figure 12   MajorRebalancing(view trees T , indicator triples T Ind , threshold θ) In conclusion, maintaining the views from Figure 12 under a single-tuple update to any relation takes O(N 3ϵ ) overall time.
We next state the complexity of updates in our approach.
Proposition 7.2. Given a hierarchical query Q(F) with dynamic width δ, a canonical variable order ω for Q, a database of size N , and ϵ ∈ [0, 1], maintaining the views in the set of view trees τ (ω, F) under a single-tuple update to any input relation takes O(N δϵ ) time.
7.2. Rebalancing Partitions. As the database evolves under updates, we periodically rebalance the relation partitions and views to account for a new database size and updated degrees of data values. The cost of rebalancing is amortized over a sequence of updates.
Major Rebalancing. We loosen the partition threshold to amortize the cost of rebalancing over multiple updates. Instead of the actual database size N , the threshold now depends on a number M for which the invariant 1 4 M ≤ N < M always holds. If the database size falls below ⌊ 1 4 M ⌋ or reaches M , we perform major rebalancing, where we halve or respectively double M , followed by strictly repartitioning the light parts of input relations with the new threshold M ϵ and recomputing the views. Figure 20 shows the major rebalancing procedure. MinorRebalancing(trees T , tree T L , tree T H , source R, key, insert) foreach T ∈ T do Apply(T, δ(∃H)) Minor Rebalancing. After an update δR = {x → m} to relation R, we check the light part and heavy part conditions of each partition of R. Consider the light part R S of R partitioned on a schema S. If the number of tuples in R S that agree with x on S exceeds 3 2 M ϵ , then we delete those tuples from R S . If the number of tuples that agree with x on S in R S is zero and in R is below 1 2 M ϵ , then we insert those tuples into R S . Figure 21 shows this minor rebalancing procedure.
Proposition 7.4. Given a hierarchical query Q(F) with dynamic width δ, a canonical variable order ω for Q, a database of size N , and ϵ ∈ [0, 1], minor rebalancing of the views in the set of view trees τ (ω, F) takes O(N (δ+1)ϵ ) time.
The cost of minor rebalancing is amortized over Ω(M ϵ ) updates. This lower bound on the number of updates is due to the gap between the two thresholds in the heavy and light part conditions. The extended technical report proves the amortized O(N δϵ ) time of minor rebalancing [KNOZ19]. Figure 22 gives the trigger procedure OnUpdate that maintains a set of view trees T and a set of indicator trees T Ind under a sequence of single-tuple updates to input relations. We first apply an update δR to the view trees from T and indicator trees from T Ind using UpdateTrees from Figure 19. If this update leads to a violation of the size invariant 1 4 M ≤ N < M , we invoke MajorRebalancing to recompute the light parts of the input relations and affected views. Otherwise, for each triple of indicator trees from T Ind with the light part R F partitioned on F, we check if the heavy or light condition is violated; if so, we invoke MinorRebalancing to move the R-tuples having the F-values of the update δR either into or from the light part R F of relation R.
We state the amortized maintenance time of our approach under a sequence of singletuple updates.  OnUpdate(view trees T , indicator triples T Ind , update δR) MinorRebalancing(T , T L , T H , R, key, false)  2 ) amortized update time and delay, which is weakly Pareto worst-case optimal: there can be no tighter upper bounds for both the update time and delay. Since w ∈ {1, 2} for δ 1 -hierarchical queries, the preprocessing time is O(N 3 2 ).

Examples Showcasing Our Approach
We exemplify our approach for the static and dynamic evaluation of two δ 1 -hierarchical queries. We start with the query from Example 2.2.  Figure 23 gives the evaluation and maintenance strategies for our query. A strategy is depicted by a view tree, with one view per node such that the head of the view is depicted at the node and its body is the join of its children.
To support light/heavy partitions, we need to keep the degree information of the Bvalues in the two relations. The light/heavy indicators can be computed in linear time, e.g., for L B we start with the light parts of R and S, aggregate away A and respectively C and then join them on B.
If  (a, c). Therefore, if we were to enumerate such tuples for one B-value after those for another B-value, the same tuple (a, c) may be output several times, which violates the enumeration constraint. To address this challenge, we use the union algorithm [DS11]. We use the N 1−ϵ buckets of (a, c) tuples, one for each heavy B-value, and an extra bucket V B (A, C) constructed in the light case. From each bucket of a B-value, we can enumerate the distinct (a, c) tuples with constant delay by looking up into R and S. The tuples in the materialized view V B (A, C) can be enumerated with constant delay. We then use the union algorithm to enumerate the distinct (a, c) tuples with delay given by the sum of the delays of the buckets. For each such tuple, we sum up the positive multiplicities of its occurrences in the buckets. This yields an overall O(N 1−ϵ ) delay for the enumeration of the distinct tuples in the result of Q. We now turn to the dynamic case. The preprocessing time and delay remain the same as in the static case, while each single-tuple update can be processed in O(N ϵ ) amortized time. To support updates, we need to maintain tuple multiplicities in addition to the degree information of the B-values in the two relations. The multiplicity of a result tuple is the sum of the multiplicities of its duplicates across the O(N 1−ϵ ) buckets. We also need two views to support efficient updates to R and S; these are marked with the dashed boxes in Figure 23. For simplicity, we assume that each view tree maintains copies of its base relations.
Consider a single-tuple update δR = {(a, b) → m} to relation R. We maintain each view affected by δR using the hierarchy of materialized views from Figure 23. The changes in those views are expressed using the classical delta rules [CY12]. We update the views R ′ (B) and The update δR may change the degree of b in R from light to heavy or vice versa. In such cases, we need to rebalance the partitioning of R and possibly recompute some of the views. Although such rebalancing steps may take time more than O(N ϵ ), they happen periodically and their amortized cost remains the same as for a single-tuple update (Section 7).
Next, we demonstrate our approach for the δ 1 -hierarchical query from Example 3.2.
Example 9.2. Consider the δ 1 -hierarchical free-connex query Q(A) = R(A, B), S(B) from Example 3.2 whose relations have size at most N . Figure 24 shows the single view tree (bottom-left) that our approach constructs in the static case, and the other five view trees needed in the dynamic case. In the static case, since Q is free-connex, its result can be computed in O(N ) time and then its tuples can be enumerated with O(1) delay. Our approach does not partition the relations in the static case. We compute the view V B (A) in

Conclusion and Future Work
This paper investigates the preprocessing-update-delay trade-off for hierarchical queries and introduces an approach that recovers a number of prior results when restricted to hierarchical queries. There are several lines of future work. Of paramount importance is the generalization of our trade-off from hierarchical to conjunctive queries. The results of this paper can be immediately extended to hierarchical queries with group-by aggregates and order-by clauses. In particular, this extension would capture the prior result on constantdelay enumeration for such queries in the context of factorized databases [OS16]. An open problem is to find lower bounds for δ i -hierarchical queries for i > 1. We conjecture our update/delay upper bounds O(N iϵ )/O(N 1−ϵ ) are worst-case optimal, as it is the case for i = 0 with ϵ = 1 [BKS17a] and i = 1 with ϵ = 1 2 (Proposition 8.1).
Appendix B. Proofs of the Results in Section 3 Theorem 3.1. Given a hierarchical query with static width w and dynamic width δ, a database of size N , and ϵ ∈ [0, 1], the query result can be enumerated with O(N 1−ϵ ) delay after O(N 1+(w−1)ϵ ) preprocessing time and O(N δϵ ) amortized update time for single-tuple updates.
The theorem follows from Propositions 5.3, 5.4, 6.1, 7.2, and 7.5. Let Q(F) be a hierarchical query and ω an arbitrary canonical variable order for Q. Without loss of generality, assume that ω consists of a single tree. The preprocessing stage materializes the views in the set of view trees returned by τ (ω, F) from Figure 11 in the dynamic mode.  Figure 11 for a given hierarchical query Q(F) and a canonical variable order ω for Q. Let Q (i) (F) be the query defined by the conjunction of the leaf atoms in T i , ∀i ∈ [k]. Then, Q(F) ≡ i∈[k] Q (i) (F).
We use two observations. (1) The procedure BuildVT constructs a view tree whose leaf atoms are exactly the same as the leaf atoms of the input variable order. (2) Each of the procedures NewVT and AuxView constructs a view tree whose set of leaf atoms is the union of the sets of leaf atoms of the input trees. For a variable order or view tree T and schema a set S of variables occurring in T , we define Q T (S) = ⋊ ⋉ R(X )∈atoms(T ) R(X ).
The proof is by induction over the structure of ω. We show that for any subtree ω ′ of ω, it holds: Base case: If ω ′ is an atom, the procedure τ returns it and the base case holds trivially.

11:38
A. Kara Case 1 does not hold and X ∈ F: The set of view trees τ (ω ′ , F) is defined as follows: for each set . Using the induction hypothesis, we rewrite as follows: Case 1 does not hold and X ̸ ∈ F: The procedure τ creates the views All X (keys) = ⋊ ⋉ R(X )∈atoms(ω ′ ) R(X ), L X (keys) = ⋊ ⋉ R(X )∈atoms(ω ′ ) R keys (X ), and H X (keys) = All X (keys) ⋊ ⋉ ∄L X (keys). It then returns the view trees {ltree} ∪ htrees defined as follows: ltree = BuildVT(·, ω keys , F), where ω keys has the same structure as ω ′ but each atom is replaced by its light part; . From ALL X (keys) = L X (keys) ∪ H X (keys), we derive the following equivalence. For simplicity, we skip the schemas of queries: Using Equivalence (C.2) and the induction hypothesis, we obtain: Proposition 5.4. Given a hierarchical query Q(F) with static width w, a canonical variable order ω for Q, a database of size N , and ϵ ∈ [0, 1], the views in the set of view trees τ (ω, F) can be materialized in O(N 1+(w−1)ϵ ) time.
We analyze the procedure τ from Figure 11 for both of the cases mode = 'static' and mode = 'dynamic'. We show that in both cases the time to materialize the set of view trees τ (ω, F) is O(N 1+(w−1)ϵ ).
We explain the intuition behind the complexity analysis. If the procedure τ runs in 'static' mode and Q is free-connex, or it runs in 'dynamic' mode and Q is δ 0 -hierarchical, the procedure constructs a view tree that can be materialized in O(N ) time. Otherwise, there must be at least one bound variable X in ω such that the subtree ω X rooted at X contains free variables. In this case, the algorithm partitions the relations at the leaves of ω X into heavy and light parts and creates view trees for computing parts of the query. The time to materialize the views of the view trees where at least one leaf relation is heavy is O(N ). The overall time to materialize the view trees τ (ω, F) is dominated by the time to materialize the views of the view trees where all leaf relations are light. In the worst case, the root variable of ω is bound and we need to materialize a view that joins the light parts of all leaf relations in ω and has the entire set F as free variables. We can compute such a view V (F) as follows. We first aggregate away all bound variables that are not ancestors of free variables in ω. By using the algorithm InsideOut [AKNR16], this can be done in O(N ) time. Then, we choose one atom to iterate over the tuples of its relation (outer loop of the evaluation). For each such tuple, we iterate over the matching tuples in the relations of the other atoms (inner loops of the evaluation). To decide which atom to take for the outer loop and which ones for the inner loops of our evaluation strategy, we use an optimal integral edge cover λ of F. The schema of each atom that is mapped to 0 by λ must be subsumed by the schema of an atom mapped to 1. Hence, we can take one of the atoms mapped to 1 to do the outer loop. The other atoms that are mapped to 1 are used for the inner loops. For the atoms that are mapped to 0, it suffices to do constant-time lookups during the iteration over the tuples of the other atoms. By exploiting the degree constraints on light relation parts, the view V (F) can be materialized in O(N 1+(ρ(F )−1)ϵ ) time. By Proposition 4.5, ρ(F) = ρ * (F). Considering the time needed to aggregate away bound variables before computing V (F), we get O(N max{1,1+(ρ * (F )−1)ϵ} ) overall time complexity. We show that max{1, 1 + (ρ * (F) − 1)ϵ} is upper-bounded by 1 + (w(Q) − 1)ϵ.
The proof is structured following the basic building blocks of the procedure τ . Lemmas C.2-C.6 give upper bounds on the times to materialize the views in the view trees returned by the procedures NewVT (Figure 7), AuxView (Figure 8) BuildVT (Figure 6), and IndicatorVTs ( Figure 10). Lemma C.7 states the complexity of the procedure τ based on a measure ξ defined over canonical variable orders. The section closes with the proof of Proposition 5.4 that bridges the measure ξ and the static width of hierarchical queries.
We introduce the measure ξ. Let ω be a canonical variable order, F ⊆ vars(ω), and X a variable or atom in ω. We denote by ω X the subtree of ω rooted at X and by Q X a query that joins the atoms at the leaves of ω X . We define If ω X does not contain a variable Y with (anc(Y ) ∪ {Y }) ̸ ⊆ F, then ξ(ω, X, F) = 0. If X has children X 1 , . . . , X k , then We start with an observation that each view V constructed by the procedures BuildVT (Figure 6), NewVT (Figure 7), AuxView (Figure 8), IndicatorVTs (Figure 10), and τ ( Figure 11) at some node X of a variable order ω contains in its schema all variables in the root path of X and no variables which are not in ω X . Moreover, V results from the join of its child views. This can be shown by a straightforward induction over the structure of ω. Observation C.1. Let ω be a canonical variable order and V (F) a view constructed at some node X of ω by one of the procedures BuildVT, NewVT, AuxView, IndicatorVTs, and τ . It holds (1) anc(X) ⊆ F ⊆ anc(X) ∪ vars(ω).
The next lemma gives a bound on the time to materialize the views in a view tree returned by the procedure NewVT in Figure 7.
Proof. The procedure NewVT defines the view V (S) = V 1 (S 1 ), . . . , V k (S k ) (Line 2). The view tree T returned by NewVT is defined as follows (Line 4): If k = 1 and S = S 1 , then T = T 1 ; otherwise, T is the view tree that has root V (S) and subtrees T 1 , . . . , T k . By assumption, the time to materialize the views in the trees T 1 , . . . , Hence, the sizes of the materialized root views Assume that the query defining V (S) is δ 0 -hierarchical. Hence, we can construct a freetop canonical variable order for the query. We materialize V (S) as follows. Traversing the variable order bottom-up, we aggregate away all bound variables using the InsideOut algorithm [AKNR16]. Since the query defining V (S) is α-acyclic, this aggregation phase can be done in time linear in the size of the views V 1 (S 1 ), . . . , V k (S k ). Thus, the aggregation phase requires O(max i∈[k] {M i }) time. It follows that the time to materialize the views in the tree returned by NewVT is O(max i∈[k] {M i }).
We proceed with a lemma that gives a bound on the time to materialize the views in the view tree returned by the procedure AuxView in Figure 8. Proof. Assume that the parameters of the procedure AuxView are Z and T . Let V (S) be the root of T . If the condition in Line 3 of the procedure AuxView does not hold, the procedure returns T (Line 5). Otherwise, it returns a view tree T ′ that results from T by adding a view V ′ (anc(Z)) on top of V (S) (Line 4). Since anc(Z) ⊂ S, V ′ (anc(Z)) results from V (S) by aggregating away the variables in S − anc(Z). Since the size of V (S) must be O(M ) and the variables can be aggregated away in time linear in the size of V (S), the overall time to materialize the views in the output tree T ′ is O(M ).
The following lemma says that if the input to the procedure BuildVT in Figure 6 represents a free-connex query, the procedure outputs a view tree whose views can be materialized in time linear in the database size.
Lemma C.4. Let ω be a canonical variable order, X a node in ω, N the size of the leaf relations of ω, and F a set of variables. If the query Q X (F ′ ) = join of atoms(ω X ) with F ′ = F ∩ (anc(X) ∪ vars(ω X )) is free-connex, the views in the view tree BuildVT(·, ω X , F) can be materialized in O(N ) time.
Proof. The proof is by induction over the structure of the variable order ω X .
Proof. In Lines 3 and 4, the procedure constructs the view tree alltree, which is defined by BuildVT("All ", ω X , keys) and the view tree ltree = BuildVT(" L ", ω keys X , keys), where keys consists of the set anc(X) ∪ {X}. The variable order ω keys X results from ω X by replacing each atom R(X ) by the atom R keys (X ), which denotes the light part of relation R partitioned on keys. These light parts can be computed in O(N ) time. The queries Q X (keys) = join of atoms(ω X ) and Q keys X (keys) = join of atoms(ω X ) are free-connex. By using Lemma C.4, we derive that the views in alltree and ltree can be materialized in O(N ) time. Hence, the roots allroot and lroot of alltree and ltree, respectively, can be materialized in O(N ) time as well. It remains to analyze the time to materialize the views in the view tree htree = NewVT(·, F, {allroot, ¬lroot}) (Line 7). It follows from Observation C.1.(1) that V (F) = allroot, ∄lroot is δ 0 -hierarchical. By using Lemma C.2, we derive that the views in htree can be materialized in O(N ) time. Overall, all views in the view trees (alltree, ltree, htree) can be materialized in O(N ) time.
We use Lemmas C.2-C.6 to show an upper bound on the time to materialize the views in any tree produced by the procedure τ in Figure 11.
The proof is by induction on the structure of ω X .
Base case: Assume that ω X is a single atom R(X ). In this case, the procedure τ returns this atom (Line 1). The atom can obviously be materialized in O(N ) time. It holds ξ(ω, X, F) = 0, since ω X does not contain any node which is a variable. This means that m = 1. Then, the statement in the lemma holds for the base case.
Inductive step: Assume that X is a variable with children nodes X 1 , . . . , X k . Let keys = anc(X) ∪ {X}, F X = anc(X) ∪ (F ∩ vars(ω X )), and Q X (F X ) = join of atoms(ω). Following the control flow in τ (ω X , F), we make a case distinction.
Case 2: Case 1 does not hold and X ∈ F (Lines 8-11): The set of view trees τ (ω X , F) is defined as follows: for each set {T i } i∈[k] with T i ∈ τ (ω X i , F), the set τ (ω X , F) contains the view tree NewVT(·, keys, {T i } i∈[k] ), whereT i = AuxView(X i , T i ) for each i ∈ [k]. We consider one such set {T i } i∈[k] of view trees. By induction hypothesis, the views in each T i can be materialized in O(N max{1,1+(ξ(ω,X i ,F )−1)ϵ} ) time. It follows from Inequality (C.3), that the overall time to materialize the views in these view trees is O(N m ). By Lemma C.3, the views in each view treeT i with i ∈ [k] can be materialized in O(N m ) time. Let V i (F i ) be the root view ofT i , for i ∈ [k]. It follows from Observation C.1.(1) that keys is included in each F i and the query V X (keys) = V 1 (F 1 ), . . . , V k (F k ) is δ 0 -hierarchical. Hence, it follows from Lemma C.2 that the views in the view tree NewVT(·, keys, {T i } i∈[k] ) can be materialized in time O(N m ). This completes the inductive step in this case.
Case 3: Case 1 does not hold and X ̸ ∈ F (Lines 12-17): The procedure τ first calls IndicatorVTs(ω X ) (Line 12) given in Figure 10, which constructs the indicator view trees alltree, ltree, and htree. By Lemma C.6, the views in these view trees can be materialized in O(N ) time. Let H X be the root of htree. The only difference between the construction of the view trees returned in Case 2 above and the view trees in the set htrees defined in Lines 13-15 is that the roots of the view trees in the latter set have ∃H X as additional child view. By the same argumentation as in Case 2, it follows that the views in htrees can be materialized in O(N m ) time. Let ltree = BuildVT(" V ", ω keys X , F X ) as defined in Line 16, where ω keys X shares the same structure as ω X , but each atom R(X ) is replaced with R keys (X ) denoting the light part of relation R partitioned on keys. It follows from Lemma C.5 that the views in the view tree ltree can be materialized in O(N m ) time. Thus, all views of the views trees in the set htrees ∪ {ltree} can be materialized in O(N m ) time. This completes the inductive step for Case 3.
Using Lemma C.7, we prove Proposition 5.4. Without loss of generality, assume that ω consists of a single connected component. Otherwise, we apply the same reasoning for each connected component. We also assume that Q contains at least one atom with non-empty schema. Otherwise, τ (ω, ∅) returns a single atom with empty schema, which can obviously be materialized in constant time.
By Lemma C.7, the view trees generated by τ (ω, F) can be materialized in time O(N max{1,1+(ξ(ω,X,F )−1)ϵ} ), where X is the root variable of ω. It remains to show: max{1, 1 + (ξ(ω, X, F) − 1)ϵ} ≤ 1 + (w − 1)ϵ. (C.5) First, assume that ξ(ω, X, F) = 0. This means that max{1, 1 + (ξ(ω, X, F) − 1)ϵ} = 1. Since Q contains at least one atom with non-empty schema, we have w ≥ 1. Thus, Inequality (C.5) holds. Now, let ξ(ω, X, F) = ℓ ≥ 1. We show that w ≥ ℓ. It follows from ξ(ω, X, F) = ℓ that ω contains a bound variable Y such that ρ * Q (B) = ℓ, where B = vars(ω Y ) ∩ F. The inner nodes of each root-to-leaf path of a canonical variable order are the variables of an atom. Hence, for each variable Z ∈ B, there must be an atom in Q that contains both Y and Z. This means that Y and Z depend on each other. Let ω ′ = (T, dep ω ′ ) be an arbitrary free-top variable order for Q. Since all variables in B depend on Y , each of them must be on a root-to-leaf path with Y . Since Y is bound and the variables in B are free, the set B must be included in anc(Y ). Hence, B ⊆ dep ω ′ (Y ). This means ρ * Q ({Y } ∪ dep ω ′ (Y )) ≥ ℓ, which implies w(ω ′ ) ≥ ℓ. It follows w ≥ ℓ.
Appendix D. Proofs of the Results in Section 6 Proposition 6.1. The tuples in the result of a hierarchical query Q(F) over a database of size N can be enumerated with O(N 1−ϵ ) delay using the view trees constructed by τ (ω, F) for a canonical variable order ω for Q.
Following Proposition 5.3, the union of queries defined by the set of view trees constructed by τ (ω, F) is equivalent Q(F). We enumerate the tuples over F from this set of view trees using the next calls of these trees in the set.
We first discuss the case of one view tree. In case there are no indicator views, then the view tree consisting of a hierarchy of views admits constant delay [OZ15]. In the static case, this holds for free-connex hierarchical queries; in the dynamic case, this holds for δ 0 -hierarchical queries (Section 5.1).
The view subtrees constructed over the light parts of input relations only do not bring additional difficulty. By construction (Section 5), the root view V of such a subtree T contains all the free variables that are present in T . In this case, the open and next calls stop at V and do not explore the children of V . This means that for enumeration purposes, we can discard the descendants of V .
By grounding the heavy indicators in T , we obtain instances of T that may represent overlapping relations. We next analyze the enumeration delay in the presence of heavy indicators as a function of the view tree instances of a view tree created for Q.
Consider one heavy indicator. Since its size is O (N 1−ϵ ), it may lead to that many view tree instances. From each instance, we can enumerate with constant delay, and we can also look up a tuple with schema S in constant time. Given there are O(N 1−ϵ ) such tuples, we can enumerate from T with O(N 1−ϵ ) delay.
Consider p heavy indicators ∃H 1 (X 1 ), . . . , ∃H p (X p ) whose parents V 1 (X 1 ), . . . , V p (X p ) are along the same path in the view tree. Let us assume V i is an ancestor of V j for i < j. By construction, there is a total strict inclusion order on their sets of variables, with the indicator above having less variables than at a lower depth: X 1 ⊂ · · · ⊂ X p . Each indicator draws its tuples from the input relations whose schemas include that of the indicator. There is also an inclusion between the parent views: V i ⊆ π X i V i+1 , ∀i ∈ [p − 1]. This holds since V i is defined by the join of the leaves underneath, so the view V j that is a descendant of V i is used to define V i in joins with other views or relations. The size of V i is at most that of ∃H i since they both have the same schema and the former is defined by the join of the latter with other views. Since the size of ∃H i is O(N 1−ϵ ), it follows that the size of V i is also O(N 1−ϵ ). When grounding ∃H i , we create an instance for each tuple t that is in both ∃H i and V i : If t were not in V i , then there would be at least one sibling of ∃H i that does not have it. When opening the descendants of V i before enumeration, only these tuples in V i that also occur in ∃H i and in all its siblings can be extended at the descendant views, including all views V j for j > i. The overall number of groundings for the h heavy indicators is therefore O(N 1−ϵ ). Let n i be the number of instances of ∃H i . Then, the delay for enumerating from the union of ∃H i instances is i≤j≤p n j using the Union algorithm, which also accounts for the delay incurred for enumeration from unions at instances of all ∃H j that are descendants of ∃H i . The overall delay is that for the union of instances for ∃H 1 : 1≤j≤p n j = O(p × N 1−ϵ ) = O(N 1−ϵ ).
Consider again the p heavy indicators, but this time their parents V 1 , . . . , V p are not all along the same path in the view tree. Each path is treated as in the previous case. We distinguish two cases. In the first case, there is no parent V i that is an ancestor of several other parents in our list. Let W be a common ancestor of several parents. Then, the enumeration algorithm uses each tuple of W (possibly extended by descendant views) as context for the instances of these parents. A next tuple is produced in sequence at each of these parents over their corresponding schemas. These tuples are then composed into a larger tuple over a larger schema at their common ancestor using the Product algorithm. The number of branches is bounded by the number of atoms in the query, which means that the overall delay remains O(N 1−ϵ ). In the second case, a parent V i is a common ancestor of several other parents in our list. We reason similarly to the one-path case and obtain that the overall delay is O(p × N 1−ϵ ) = O(N 1−ϵ ).
So far we discussed the case of enumerating from one view tree. In case of a set of view trees we use the Union algorithm to enumerate the distinct tuples. In case the query has several connected components, i.e., it is a Cartesian product of hierarchical queries, we use the Product algorithm.