Optimal Join Algorithms meet Top- Nikolaos Tziavelis, Wolfgang - - PowerPoint PPT Presentation

1

Optimal Join Algorithms meet Top-𝑙

SIGMOD 2020 tutorial Nikolaos Tziavelis, Wolfgang Gatterbauer, Mirek Riedewald Northeastern University, Boston

Slides: https://northeastern-datalab.github.io/topk-join-tutorial/ DOI: https://doi.org/10.1145/3318464.3383132 Data Lab: https://db.khoury.northeastern.edu

Ranked results Time

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 4.0 International License. See https://creativecommons.org/licenses/by-nc-sa/4.0/for details

Part 2 : Optimal Join Algorithms

2

Outline tutorial

• Part 1: Top-𝑙 (Wolfgang): ~20min
• Part 2: Optimal Join Algorithms (Mirek): ~30min

– Lower Bound and the Yannakakis Algorithm – Problems Caused by Cycles – Tree Decompositions – Summary and Further Reading

• Part 3: Ranked enumeration over joins (Nikolaos): ~40min

3

Basic Terminology and Assumptions

• Terminology
• Full conjunctive query (CQ)
• Natural join of 𝑚 relations with O(𝑜) tuples each
• E.g.: 𝑅 𝐵1, 𝐵2, 𝐵3, 𝐵4 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4
• Any selections comparing attributes to constants, e.g., 𝐵4 < 1
• Query size: O(𝑚)
• Output cardinality: 𝑠
• Assumptions
• No pre-computed data structures such as indexes, sorted representation,

materialized views

4

Complexity Notation

• Standard O and Ω notation for time and memory complexity in the

RAM model of computation

• Common practice: focus on data complexity
• We care about scalability in data size
• Treat query size 𝑚 as a constant
• E.g., O 𝑔 𝑚 ⋅ 𝑜𝑔(𝑚) + log 𝑜 𝑔(𝑚) ⋅ 𝑠 simplifies to O 𝑜𝑔(𝑚) + log 𝑜 𝑔(𝑚) ⋅ 𝑠

5

Complexity Notation

• Standard O and Ω notation for time and memory complexity in the

RAM model of computation

• Common practice: focus on data complexity
• We care about scalability in data size
• Treat query size 𝑚 as a constant
• E.g., O 𝑔 𝑚 ⋅ 𝑜𝑔(𝑚) + log 𝑜 𝑔(𝑚) ⋅ 𝑠 simplifies to O 𝑜𝑔(𝑚) + log 𝑜 𝑔(𝑚) ⋅ 𝑠
• We mostly use ෩

O-notation (soft-O) data complexity

• Abstracts away polylog factors in input size that clutter formulas
• E.g., O 𝑜𝑔(𝑚) + log𝑜 𝑔(𝑚) ⋅ 𝑠 further simplifies to ෩

O 𝑜𝑔(𝑚) + 𝑠

6

Outline tutorial

• Part 1: Top-𝑙 (Wolfgang): ~20min
• Part 2: Optimal Join Algorithms (Mirek): ~30min

– Lower Bound and the Yannakakis Algorithm – Problems Caused by Cycles – Tree Decompositions – Summary and Further Reading

• Part 3: Ranked enumeration over joins (Nikolaos): ~40min

7

Lower Bound for Any Query

• Need to read entire input at least once: Ω(𝑚𝑜)
• Ω(𝑜) data complexity
• Need to output every result, each of size 𝑚: Ω(𝑚𝑠)
• Ω(𝑠) data complexity
• Together: Ω(𝑜 + 𝑠) time complexity to compute any CQ
• Amazingly, the Yannakakis algorithm essentially matches the lower

bound for acyclic CQs

• Time complexity ෩

O 𝑜 + 𝑠

8

Yannakakis Algorithm

• Given: acyclic conjunctive query Q as a rooted join tree
• Step 1: semi-join reduction (two sweeps)
• Semi-join reduction sweep from the leaves to root
• Semi-join reduction sweep from root to the leaves
• Step 2: use the join tree as the query plan
• Compute the joins bottom up, with early projections

[Mihalis Yannakakis. Algorithms for acyclic database schemes. VLDB’81] https://dl.acm.org/doi/10.5555/1286831.1286840

9

Database Theory

Yannakakis Algorithm – Example

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4 𝐵2 𝐵1, 𝐵2 𝐵1, 𝐵2

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4

10

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3 𝐵2 𝐵1, 𝐵2

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟑 ⋉ 𝑺𝟓

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4 𝐵1, 𝐵2

11

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4 𝐵2 𝐵1, 𝐵2

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟑 ⋉ 𝑺𝟓

𝑩𝟐 𝑩𝟑 1 10 1 20 2 20

12

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4 𝐵2 𝐵1, 𝐵2

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟑 ⋉ 𝑺𝟓

𝑩𝟐 𝑩𝟑 1 10 1 20 2 20

13

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4 𝐵1, 𝐵2

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟑 ⋉ 𝑺𝟓

𝑩𝟐 𝑩𝟑 1 10 1 20 2 20

𝑺𝟑 ⋉ 𝑺𝟒

𝑩𝟑 10 20 30

14

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟑 ⋉ 𝑺𝟓

𝑩𝟐 𝑩𝟑 1 10 1 20 2 20

𝑺𝟑 ⋉ 𝑺𝟒

𝑩𝟑 10 20 30

𝑺𝟐 ⋉ 𝑺𝟑

𝑩𝟐 𝑩𝟑 1 10 1 20

15

Database Theory

Yannakakis Algorithm – Example

1.

Bottom-up traversal (semi-joins)

2.

Top-down traversal (semi-joins)

𝑩𝟐 𝑩𝟑 1 20 1 10 4 60

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100 3 10 300 1 40 300 2 30 200

𝑆2

𝑩𝟑 10 20 30

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000 2 20 2000

𝑆4

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4 𝑺𝟓 ⋉ 𝑺𝟑 𝑺𝟒 ⋉ 𝑺𝟑 𝑺𝟑 ⋉ 𝑺𝟐

16

Database Theory

Yannakakis Algorithm – Example

𝑩𝟐 𝑩𝟑 1 20 1 10

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100

𝑆2

𝑩𝟑 10 20

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000

𝑆4

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4

1.

Bottom-up traversal (semi-joins)

2.

Top-down traversal (semi-joins)

3.

Join bottom-up

17

Database Theory

Yannakakis Algorithm – Example

𝑩𝟐 𝑩𝟑 1 20 1 10

𝑆1

𝑩𝟐 𝑩𝟑 𝑩𝟒 1 10 100 1 20 100

𝑆2

𝑩𝟑 10 20

𝑆3

𝑩𝟐 𝑩𝟑 𝑩𝟓 1 10 1000 1 20 1000 1 20 2000

𝑆4

𝑅 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵1, 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵2 ⋈ 𝑆4 𝐵1, 𝐵2, 𝐵4

1.

Bottom-up traversal (semi-joins)

2.

Top-down traversal (semi-joins)

3.

Join bottom-up In each join step, each left input tuple joins with at least 1 right input tuple, and vice versa!

18

Yannakakis Algorithm – Properties

• Semi-join sweeps take ෩

O 𝑜

• A join step can never shrink intermediate result size
• This does not hold for all trees
• Tree must be attribute-connected (more on this soon)
• Hence all intermediate results are of size O 𝑠
• Each join step therefore has O 𝑜 + 𝑠 input and O 𝑠 output
• Easy to compute a binary join with O 𝑜 + 𝑠 input and O 𝑠 output

in time ෩ O 𝑜 + 𝑠 , e.g., using sort-merge join

19

Outline tutorial

• Part 1: Top-𝑙 (Wolfgang): ~20min
• Part 2: Optimal Join Algorithms (Mirek): ~30min

– Lower Bound and the Yannakakis Algorithm – Problems Caused by Cycles – Tree Decompositions – Summary and Further Reading

• Part 3: Ranked enumeration over joins (Nikolaos): ~40min

20

CQs with Cycles

• 3-path: 𝑅3𝑞 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵4)
• 3-cycle: 𝑅3𝑑 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵1)

𝑅3𝑞 𝑅3𝑑 𝐵1 𝐵2 𝐵2 𝐵3 𝐵3 𝐵4 𝐵1 𝐵2 𝐵3 𝐵2 𝐵3 𝐵1

21

CQs with Cycles

• 3-path: 𝑅3𝑞 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵4)
• 3-cycle: 𝑅3𝑑 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵1)
• Already semi-join-reduced input

𝑩𝟐 𝑩𝟑 1 1 2 1 … … n 1 𝑩𝟑 𝑩𝟒 1 1 1 2 … … 1 n 𝑩𝟒 * 1 1 2 2 … … n n

𝑆1

𝑆1 𝑆2

Join tree

𝑆3

𝑆2 𝑆3

22

CQs with Cycles

• 3-path: 𝑅3𝑞 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵4)
• 3-cycle: 𝑅3𝑑 = 𝑆1(𝐵1, 𝐵2) ⋈ 𝑆2(𝐵2, 𝐵3) ⋈ 𝑆3(𝐵3, 𝐵1)
• Already semi-join reduced in the example
• 𝑆1 ⋈ 𝑆2 produces 𝑜2 intermediate results
• Final output size: 𝑜2 for 𝑅3𝑞, but only 𝑜 for 𝑅3𝑑

𝑩𝟐 𝑩𝟑 1 1 2 1 … … n 1 𝑩𝟑 𝑩𝟒 1 1 1 2 … … 1 n 𝑩𝟒 * 1 1 2 2 … … n n

𝑆1

𝑆1 𝑆2

Join tree

𝑆3

𝑆2 𝑆3

23

What Went Wrong?

• The tree for the 3-cycle is not attribute-connected!
• Attribute-connectedness:
• For each attribute, the nodes containing it form a connected sub-graph
• In the right tree, 𝐵1 violates this property

𝑆1(𝐵1, 𝐵2) 𝑆2(𝐵2, 𝐵3) 𝑆3(𝐵3, 𝐵4) 𝑅3𝑞 𝑅3𝑑 𝑆1(𝐵1, 𝐵2) 𝑆2(𝐵2, 𝐵3) 𝑆3(𝐵3, 𝐵1)

24

Solutions for Cycles? Some Bad News

• Maybe we just need an algorithm that is better suited for cyclic

CQs?

• Yes, but…
• … [Ngo+ 18]:
• ෩

O 𝑜 + 𝑠 unattainable based on well-accepted complexity-theoretic assumptions

[Ngo+ 18] Ngo, Porat, Ré, Rudra. Worst-case optimal join algorithms. J. ACM’18 https://doi.org/10.1145/3180143

25

What Can Be Done?

• Worst-case-optimal (WCO) join

algorithms [Veldhuizen 14, Ngo+ 14, Ngo+ 18]

• Instead of ෩

O 𝑜 + 𝑠 , get ෩ O 𝑜 + 𝑠

WC = ෩

O 𝑠

WC

• 𝑠

WC = largest output of Q over any

possible DB instance

• Determined by the AGM bound[4]
• Based on fractional edge cover of the

join hypergraph

• 3-cycle: 𝑜1.5 vs naive upper bound 𝑜3

[Ngo+ 18] Ngo, Porat, Ré, Rudra. Worst-case optimal join algorithms. J. ACM’18 https://doi.org/10.1145/3180143 [Veldhuizen 14] Veldhuizen. Triejoin: A simple, worst-case optimal join algorithm. ICDT’14 https://doi.org/10.5441/002/icdt.2014.13 [Ngo+ 14] Ngo, Re, Rudra. Skew strikes back: New developments in the theory of join algorithms. SIGMOD Rec.’14 https://doi.org/10.1145/2590989.2590991 [Atserias+ 13] Atserias, Grohe, Marx. Size bounds and query plans for relational joins. . SIAM J. Comput.’13 https://doi.org/10.1137/110859440

26

What Can Be Done?

• Worst-case-optimal (WCO) join

algorithms [Veldhuizen 14, Ngo+ 14, Ngo+ 18]

• Instead of ෩

O 𝑜 + 𝑠 , get ෩ O 𝑜 + 𝑠

WC = ෩

O 𝑠

WC

• 𝑠

WC = largest output of Q over any

possible DB instance

• Determined by the AGM bound[4]
• Based on fractional edge cover of the

join hypergraph

• 3-cycle: 𝑜1.5 vs naive upper bound 𝑜3
• Tree decompositions
• Put more effort into pre-processing

to avoid large intermediate results

• Use WCO joins as sub-routine
• Goal: ෩

O 𝑜𝑒 + 𝑠 for smallest 𝑒 possible

• ෩

O 𝑜𝑒 captures pre-processing cost

• 𝑒 = 1 for acyclic CQ

[Ngo+ 18] Ngo, Porat, Ré, Rudra. Worst-case optimal join algorithms. J. ACM’18 https://doi.org/10.1145/3180143 [Veldhuizen 14] Veldhuizen. Triejoin: A simple, worst-case optimal join algorithm. ICDT’14 https://doi.org/10.5441/002/icdt.2014.13 [Ngo+ 14] Ngo, Re, Rudra. Skew strikes back: New developments in the theory of join algorithms. SIGMOD Rec.’14 https://doi.org/10.1145/2590989.2590991 [Atserias+ 13] Atserias, Grohe, Marx. Size bounds and query plans for relational joins. . SIAM J. Comput.’13 https://doi.org/10.1137/110859440

27

Outline tutorial

• Part 1: Top-𝑙 (Wolfgang): ~20min
• Part 2: Optimal Join Algorithms (Mirek): ~30min

– Lower Bound and the Yannakakis Algorithm – Problems Caused by Cycles – Tree Decompositions – Summary and Further Reading

• Part 3: Ranked enumeration over joins (Nikolaos): ~40min

28

Main Idea of Tree Decompositions

• Convert cyclic CQ to a rooted tree-shaped CQ

A1 A4 A3 A2 A6 A5 R6 R1 R2 R3 R4 R5 S = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 T = 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5 𝐵5, 𝐵6 ⋈ 𝑆6(𝐵6, 𝐵1)

decomposition

29

Main Idea of Tree Decompositions

• Convert cyclic CQ to a rooted tree-shaped CQ
• Materialize all tree nodes (“bags”) using a WCO join algorithm

A1 A4 A3 A2 A6 A5 R6 R1 R2 R3 R4 R5 S = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 T = 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5 𝐵5, 𝐵6 ⋈ 𝑆6(𝐵6, 𝐵1)

decomposition

S T

30

Main Idea of Tree Decompositions

• Convert cyclic CQ to a rooted tree-shaped CQ
• Materialize all tree nodes (“bags”) using a WCO join algorithm
• Apply Yannakakis algorithm on the tree
• Acyclic CQ whose input relations are the bags
• Achieves ෩

O 𝑦 + 𝑠 where 𝑦 is the size of the largest bag

A1 A4 A3 A2 A6 A5 R6 R1 R2 R3 R4 R5 S = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 T = 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5 𝐵5, 𝐵6 ⋈ 𝑆6(𝐵6, 𝐵1)

decomposition

S T

Yannakakis

31

Tree Decomposition Intuition

𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

32

Tree Decomposition Intuition

𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1) Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

33

Tree Decomposition Intuition

𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1) Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

34

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4 𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

1

Bag materialization costs O(𝑜3) (AGM bound)

35

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4 𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

1

Bag materialization costs O(𝑜3) (AGM bound)

36

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

Bag materialization costs O(𝑜2) (AGM bound) 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

37

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

Bag materialization costs O(𝑜2) (AGM bound) 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

38

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 𝑆3 𝐵3, 𝐵4 𝑆4 𝐵4, 𝐵5 𝑆5 𝐵5, 𝐵6 𝑆6(𝐵6, 𝐵1)

O(𝑜) bag materialization…? 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

39

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

𝒰

3

𝑆1 𝑩𝟐, 𝐵2 𝑆2 𝐵2, 𝐵3 𝑆3 𝐵3, 𝐵4 𝑆4 𝐵4, 𝐵5 𝑆5 𝐵5, 𝐵6 𝑆6(𝐵6, 𝑩𝟐)

𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

40

Tree Decomposition Intuition

Every relation appearing in the query is covered by a bag (tree node) For each attribute, the bags containing it are connected

𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

O 𝑜 ∙ 𝜌𝐵1 𝑆1 bag materialization: still O(𝑜2) 𝑅6𝑑 𝐵1, … , 𝐵6 = 𝑆1 𝐵1, 𝐵2 ⋈ 𝑆2 𝐵2, 𝐵3 ⋈ 𝑆3 𝐵3, 𝐵4 ⋈ 𝑆4 𝐵4, 𝐵5 ⋈ 𝑆5(𝐵5, 𝐵6) ⋈ 𝑆6(𝐵6, 𝐵1)

41

Tree Decomposition: Formal Definition

• Given: hypergraph ℋ = (𝒲, ℰ)
• 𝒲: attributes
• E.g., 𝐵1, 𝐵2, 𝐵3, 𝐵4, 𝐵5, 𝐵6
• ℰ: relations
• E.g., 𝑆3 is hyperedge (𝐵3, 𝐵4)
• A tree decomposition of ℋ is a pair 𝒰, 𝜓 where
• 𝒰 = 𝑊 𝒰 ,𝐹(𝒰) is a tree
• 𝜓: 𝑊 𝒰 → 2𝒲 assigns a bag 𝜓(𝑤) to each tree node 𝑤 such that
• Each hyperedge 𝐺 ∈ ℰ is covered, i.e., ∀𝐺 ∈ ℰ: ∃𝑤 ∈ 𝑊 𝒰 : 𝐺 ⊆ 𝜓(𝑤)
• For each 𝑣 ∈ 𝒲, the bags containing 𝑣 are connected

A1 A4 A3 A2 A6 A5 R6 R1 R2 R3 R4 R5 𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

[Khamis, Ngo, Suciu. What do shannon-type inequalities, submodular width, and disjunctive datalog have to do with one another? PODS’17]

https://doi.org/10.1145/3034786.3056105

42

Tree-Decomposition Properties

• Query has multiple decompositions—which is best?

43

Tree-Decomposition Properties

• Query has multiple decompositions—which is best?
• Consider a tree with O(𝑚) nodes, each materialized using WCO join
• Worst-case output of bag 𝑗 is of size O(𝑜𝑒𝑗) for some 𝑒𝑗 ≥ 1 (AGM bound)
• Fractional hypertree width (fhw) 𝑒 = max

𝑗

𝑒𝑗 [Grohe+ 14]

• Total bag-materialization cost: O(𝑜𝑒)
• Size of a materialized bag: O(𝑜𝑒)
• Resulting cost for Yannakakis algorithm on materialized tree: ෩

O(𝑜𝑒 + 𝑠)

[Grohe+ 14] Grohe and Marx. Constraint solving via fractional edge covers. ACM TALG’14. https://doi.org/10.1145/2636918

44

Who Wins?

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4 𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

1

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

𝓤𝟐 > 𝓤𝟑 = 𝓤𝟒

O(𝑜2) O(𝑜2) O(𝑜3)

45

A Closer Look

• 𝒰

1 loses, because it does not decompose the query

46

A Closer Look

• 𝒰

1 loses, because it does not decompose the query

• Are 𝒰

2 and 𝒰 3 really equally good?

• In 𝒰

2, bag computation requires joining 3 relations

• In 𝒰

3, at most 2 relations are joined

• One of them is just the set of distinct 𝐵1-values in 𝑆1

47

A Closer Look

• 𝒰

1 loses, because it does not decompose the query

• Are 𝒰

2 and 𝒰 3 really equally good?

• In 𝒰

2, bag computation requires joining 3 relations

• In 𝒰

3, at most 2 relations are joined

• One of them is just the set of distinct 𝐵1-values in 𝑆1
• 𝒰

3 is better when the number of distinct 𝐵1-values in 𝑆1 is low, e.g.,

𝑃(𝑜2/3) instead of 𝑃 𝑜

48

Who Wins? 𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

Degree constraint: 𝜌𝐵1 𝑆1 ≤ 𝑜2/3 O(𝑜) O(𝑜) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3)

“The number of distinct 𝐵1 values in 𝑆1 is at most 𝑜2/3”

49

Who Wins?

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

Degree constraint: 𝜌𝐵1 𝑆1 ≤ 𝑜2/3 O(𝑜) O(𝑜) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3) O(𝑜2) O(𝑜2)

50

Could 𝒰

2 Win?

• Consider bag 𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4 in 𝒰

2

• What if each 𝑆1-tuple joins with only “a few” 𝑆2-tuples?
• What if each 𝑆2-tuple joins with only “a few” 𝑆3-tuples?
• What if “a few” was 𝑜1/3?

51

Who Wins Now?

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

Degree constraint: ∀𝑗 ∈ {2,3,5,6}: ∀𝑘: 𝜌𝐵𝑗+1𝜏

𝐵𝑗=𝑘 𝑆𝑗

≤ 𝑜1/3 O(𝑜5/3) O(𝑜5/3)

52

Who Wins Now?

𝑆1 𝐵1, 𝐵2 , 𝑆2 𝐵2, 𝐵3 , 𝑆3 𝐵3, 𝐵4

𝒰

2

𝑆4 𝐵4, 𝐵5 , 𝑆5 𝐵5, 𝐵6 , 𝑆6(𝐵6, 𝐵1)

𝒰

3

𝑆1 𝐵1, 𝐵2 𝑆2 𝐵2, 𝐵3 , 𝑆1 𝐵1, _ 𝑆3 𝐵3, 𝐵4 , 𝑆1 𝐵1, _ 𝑆4 𝐵4, 𝐵5 , 𝑆1 𝐵1, _ 𝑆5 𝐵5, 𝐵6 , 𝑆1 𝐵1, _ 𝑆6(𝐵6, 𝐵1)

Degree constraint: ∀𝑗 ∈ {2,3,5,6}: ∀𝑘: 𝜌𝐵𝑗+1𝜏

𝐵𝑗=𝑘 𝑆𝑗

≤ 𝑜1/3 O(𝑜) O(𝑜) O(𝑜2) O(𝑜2) O(𝑜2) O(𝑜2) O(𝑜5/3) O(𝑜5/3)

53

Best of Both Worlds

• Depending on the degree constraints that hold for a DB instance, we

may sometimes prefer 𝒰

2 and sometimes 𝒰 3

• What if we used both? [Alon+ 97, Marx 13]
• Intuition: each decomposition is a different query “plan”
• Query output = union of individual plans’ results
• Decide for each input tuple to which plan(s) to send it
• Main idea: split each input relation into heavy and light
• Goal: enforce desirable degree constraints for each tree

[Marx 13] Marx. Tractable hypergraph properties for constraint satisfaction and conjunctive queries. J.ACM’13 https://doi.org/10.1145/2535926 [Alon+ 97] Alon, Yuster, Zwick. Finding and counting given length cycles. Algorithmica’97 https://doi.org/10.1007/BF02523189

54

Multiple Plans: Plan 1 𝒰

3

𝑆1

𝐼 𝐵1, 𝐵2

𝑆2 𝐵2, 𝐵3 , 𝑆1

𝐼 𝐵1, _

𝑆3 𝐵3, 𝐵4 , 𝑆1

𝐼 𝐵1, _

𝑆4 𝐵4, 𝐵5 , 𝑆1

𝐼 𝐵1, _

𝑆5 𝐵5, 𝐵6 , 𝑆1

𝐼 𝐵1, _

𝑆6(𝐵6, 𝐵1)

𝑆1

𝐼: contains all tuples whose

𝐵1-values occur more than 𝑜1/3 times (fewer than 𝑜2/3 such 𝐵1-values exist)

55

Multiple Plans: Plan 1 𝒰

3: computes 𝑆1

𝐼 ⋈ 𝑆2 ⋈ ⋯ ⋈ 𝑆6

𝑆1

𝐼 𝐵1, 𝐵2

𝑆2 𝐵2, 𝐵3 , 𝑆1

𝐼 𝐵1, _

𝑆3 𝐵3, 𝐵4 , 𝑆1

𝐼 𝐵1, _

𝑆4 𝐵4, 𝐵5 , 𝑆1

𝐼 𝐵1, _

𝑆5 𝐵5, 𝐵6 , 𝑆1

𝐼 𝐵1, _

𝑆6(𝐵6, 𝐵1)

Degree constraint: 𝜌𝐵1 𝑆1

𝐼

≤ 𝑜2/3 O(𝑜) O(𝑜) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3) O(𝑜5/3)

𝑆1

𝐼: contains all tuples whose

𝐵1-values occur more than 𝑜1/3 times (fewer than 𝑜2/3 such 𝐵1-values exist)

56

More Plans

• Note that
• 𝑅6𝑑 = 𝑆1 ⋈ 𝑆2 ⋈ 𝑆3 ⋈ 𝑆4 ⋈ 𝑆5 ⋈ 𝑆6 together with
• 𝑆1

𝑀 = 𝑆1 ∖ 𝑆1 𝐼

• implies that 𝑅6𝑑 is the union of
• 𝑆1

𝐼 ⋈ 𝑆2 ⋈ 𝑆3 ⋈ 𝑆4 ⋈ 𝑆5 ⋈ 𝑆6 and

• 𝑆1

𝑀 ⋈ 𝑆2 ⋈ 𝑆3 ⋈ 𝑆4 ⋈ 𝑆5 ⋈ 𝑆6

• To compute the latter, apply the same trick to 𝑆2

57

Multiple Plans: Plan 2 𝒰

3: computes 𝑆1

𝑀 ⋈ 𝑆2 𝐼 ⋈ 𝑆3 ⋈ ⋯ ⋈ 𝑆6

𝑆2

𝐼 𝐵2, 𝐵3

𝑆3 𝐵3, 𝐵4 , 𝑆2

𝐼 𝐵2, _

𝑆4 𝐵4, 𝐵5 , 𝑆2

𝐼 𝐵2, _

𝑆5 𝐵5, 𝐵6 , 𝑆2

𝐼 𝐵2, _

𝑆6 𝐵6, 𝐵1 , 𝑆2

𝐼 𝐵2, _

𝑆1

𝑀(𝐵1, 𝐵2)

Degree constraint: 𝜌𝐵2 𝑆2

𝐼

≤ 𝑜2/3

𝑆2

𝐼: contains all tuples whose

𝐵2-values occur more than 𝑜1/3 times (fewer than 𝑜2/3 such 𝐵2-values exist)

𝑆2

𝑀 = 𝑆2 ∖ 𝑆2 𝐼

58

Plans 3 to 6

• Plans discussed so far
• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝐼 ⋈ 𝑆4 ⋈ 𝑆5 ⋈ 𝑆6

• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝑀 ⋈ 𝑆4 𝐼 ⋈ 𝑆5 ⋈ 𝑆6

• Continue analogously to compute
• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝐼 ⋈ 𝑆4 ⋈ 𝑆5 ⋈ 𝑆6

• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝑀 ⋈ 𝑆4 𝐼 ⋈ 𝑆5 ⋈ 𝑆6

• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝑀 ⋈ 𝑆4 𝑀 ⋈ 𝑆5 𝐼 ⋈ 𝑆6

• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝑀 ⋈ 𝑆4 𝑀 ⋈ 𝑆5 𝑀 ⋈ 𝑆6 𝐼

• What is missing?

59

The 7-th Plan

• Join all light-only partitions with each other:
• 𝑆1

𝑀 ⋈ 𝑆2 𝑀 ⋈ 𝑆3 𝑀 ⋈ 𝑆4 𝑀 ⋈ 𝑆5 𝑀 ⋈ 𝑆6 𝑀

• Input now satisfies the other degree constraint:
• ∀𝑗 ∈ {2,3,5,6}: ∀𝑘: 𝜌𝐵𝑗+1𝜏

𝐵𝑗=𝑘 𝑆𝑗

≤ 𝑜1/3

• Use decomposition 𝒰

2 for it!

60

Analysis and Discussion

• Rewrite 6-cycle into 7 sub-queries
• Six of them use 𝒰

3, copying the heavy attribute to intermediate bags

• One uses 𝒰

2 on the all-light case

• Analysis
• Assigning input tuples to subqueries:

O(𝑜)

• Bag materialization:

O(𝑜5/3)

• Bag size:

O(𝑜5/3)

• Running Yannakakis on each of the 7 trees takes ෩

O 𝑜5/3 + 𝑠

• Beats single-tree complexity ෩

O 𝑜2 + 𝑠 and WCO-join complexity ෩ O 𝑜3

61

Tree Decompositions: The Big Picture

• WCO join algorithms applied to a query Q: complexity determined

by the AGM bound for Q

• Decomposing Q into a tree creates bags that each may have a lower

AGM bound value (fractional hypertree width)

• This reduces time complexity
• Materialize each bag using a WCO join algorithm
• Run Yannakakis algorithm on the tree with materialized bags as input
• Design goal: minimize width of tree, but ensure that each input

relation is covered by a bag and the tree is attribute-connected!

62

Tree Decompositions: Degree Constraints

• Degree constraints generalize cardinality constraints and functional

dependencies

• Enable improved complexity guarantees
• Application to general input (with only cardinality constraints):
• Partition input so that each partition satisfies stronger degree constraints
• Use appropriate tree for each partition
• Current frontier: submodular width
• Application to input DB with degree constraints:
• Degree-aware submodular width

[Khamis, Ngo, Suciu. What do shannon-type inequalities, submodular width, and disjunctive datalog have to do with one another? PODS’17] https://doi.org/10.1145/3034786.3056105 [Joglekar, Ré. It's all a matter of degree. Theory of Computing Systems’18] https://doi.org/10.1007/s00224-017-9811-8 [Marx. Tractable hypergraph properties for constraint satisfaction and conjunctive queries. J.ACM’13] https://doi.org/10.1145/2535926

63

Outline tutorial

• Part 1: Top-𝑙 (Wolfgang): ~20min
• Part 2: Optimal Join Algorithms (Mirek): ~30min

– Lower Bound and the Yannakakis Algorithm – Problems Caused by Cycles – Tree Decompositions – Summary and Further Reading

• Part 3: Ranked enumeration over joins (Nikolaos): ~40min

64

Optimal-Joins Summary

• On acyclic CQs, the Yannakakis algorithm’s complexity ෩

O 𝑜 + 𝑠 matches the lower bound

• Simple join-at-a-time query plan after semi-join reduction sweeps
• Lower bound cannot be matched for general cyclic CQs
• WCO joins achieve ෩

O 𝑜 + 𝑠WC

• “Holistic” multi-way join approach
• Tree decomposition approaches achieve ෩

O 𝑜𝑒 + 𝑠

• Best 𝑒 is submodular width subw(Q) using multi-tree decomposition
• 𝑜subw(𝑅) = O(𝑠

WC), but usually better

• 6-cycle: 𝑠WC = 𝑜3, but multi-tree approach achieves ෩

O 𝑜5/3 + 𝑠

65

Further Reading

• Extensions of the query model
• Projections and aggregation
• Factorized DB
• Stronger notions of optimality
• …and many more (see our tutorial paper)

[Khamis, Ngo, Rudra. FAQ: questions asked frequently. PODS’16] https://doi.org/10.1145/2902251.2902280 [Bakibayev, Kočiský, Olteanu, Závodný. Aggregation and Ordering in Factorised Databases. PVLDB’13] https://doi.org/10.14778/2556549.2556579 [Bakibayev, Olteanu, Závodný. FDB: A Query Engine for Factorised Relational Databases. PVLDB’12] https://doi.org/10.14778/2350229.2350242 [Olteanu, Schleich. Factorized databases. SIGMOD Record’16] https://doi.org/10.1145/3003665.3003667 [Olteanu, Závodny. Size bounds for factorised representations of query results. TODS’15] https://doi.org/10.1145/2656335 [Khamis, Ré, Rudra. Joins via Geometric Resolutions: Worst Case and Beyond. TODS’16] https://doi.org/10.1145/2967101 [Ngo, Nguyen, Re, Rudra. Beyond worst-case analysis for joins with minesweeper. PODS’14] https://doi.org/10.1145/2594538.2594547