"DPLL" is Worst Case Optimal
Florent Capelli, Oliver Irwin, Sylvain Salvati
CRIL, Université d’Artois
Séminaire du CRIL
11 November 2025
Joining like a DB Dude
|
|
|
|
|
|
0
|
0
|
|
|
0
|
1
|
|
|
2
|
1
|
|
|
|
|
|
|
0
|
0
|
|
|
0
|
2
|
|
|
2
|
3
|
|
|
|
|
|
|
0
|
2
|
|
|
1
|
0
|
|
|
1
|
2
|
- Devise a query plan:
- Materialize the intermediate joins.
|
|
|
|
|
|
|
0
|
0
|
0
|
|
|
0
|
0
|
2
|
|
|
0
|
1
|
0
|
|
|
0
|
1
|
2
|
|
|
2
|
1
|
3
|
Joining like a SAT Guy
|
|
|
|
|
|
0
|
0
|
|
|
0
|
1
|
|
|
2
|
1
|
|
|
|
|
|
|
0
|
0
|
|
|
0
|
2
|
|
|
2
|
3
|
|
|
|
|
|
|
0
|
2
|
|
|
1
|
0
|
|
|
1
|
2
|
Disruptive poll
In theory, is it better to do a database join like:
- A DB Dude
- A SAT guy
No confidence vote
- Go home, you are not qualified to talk about joins after saying dumb
things like that.
- This is LE CRIL. We do SAT
before breakfast everyday. Some of us even replace
sugar with GLUCOSE in their coffee. Tell us the whole story
What is wrong with joining like a pro
- It is known that if
,
then
.
-
may have
answers!
Worst scenario for query plans
Consider
on domain
with:
- .
|
|
|
|
|
|
0
|
|
|
|
|
0
|
|
|
|
|
|
|
0
|
|
|
|
|
0
|
|
|
|
|
|
|
0
|
|
|
|
|
0
|
- ,
,
- .
Every query plan will materialize a table of size
but the answer table will never be of size greater than
.
And the brute?
Domain
with
and
.
|
|
|
|
|
|
0
|
|
|
|
|
0
|
|
|
|
|
|
|
0
|
|
|
|
|
0
|
|
|
|
|
|
|
0
|
|
|
|
|
0
|
![]()
If we do the “else” branches efficiently (e.g. by reading values from
one table), the algorithm makes
recursive calls.
Worst-case optimal join
Ideal complexity: output
in time
…
… unlikely to be possible.
Worst case optimal: output
in time
.
is the size of the largest input relation and
ignores polylog factors.
:
data complexity, ie,
is considered constant. Ideally,
is a reasonable polynomial though.
Worst case value
Consider a join query
and all databases for
with a bound
on the table size:
and let:
is the worst case: the size of the biggest answer set
possible with query
and databases where each table are bounded by
.
Worst case examples
- Cartesian product:
has
.
- Similarly:
has
.
- Square query:
has
.
- Triangle query:
,
.
- The n-cycle:
:
.
We know how to compute
such that
but we do not need it!
This is known as the AGM-bound
Worst case optimal join (WCOJ) algorithms
A join algorithm is worst case optimal (wrt
)
if for every
,
and
,
it computes
in time
- Data complexity model:
considered constant hence
also.
- In this talk,
will be a reasonable polynomial!
The DBMS approach is not worst case optimal (triangle example from
before).
Existing WCOJ Algorithm
Rich literature:
- NPRR join (Ngo, Porat, Ré, Rudra, PODS12): usual
join plans but with relations partitionned into high/low degree
tuples.
- Leapfrog Triejoin (Veldhuizen, ICDT14)
- Generic Join (Ngo, PODS18): both branch and bound
algorithms as ours but more complex analysis/data structures.
- PANDA (PODS17): handle complex database
constraints, very complex, long analysis.
We prove the worst case optimality of the branch and bound algorithm
in an elementary way.
Worst case and functional dependencies
Functional dependencies
.
We have:
.
What if we know that every database verify a key constraint
?
(ie fixing the value of
fixes the value of
).
The worst case is
on such database!
Worst-case and constraints
:
- Worst case for any database whose relation have size at most
,
- ie every database respecting a cardinality
constraint.
- Worst case for any database whose relation have size at most
and respecting some “simple” functional dependencies.
- May be smaller than
:
- More generally, worst case for a class
of databases.
- More complex functional depencies
.
- “Statistical” constraints (degree constraints)
Back to the example
.
We have:
- .
- .
Is our algorithm worst-case optimal for this class?
Yes if
is set before
:
UNIT PROPAGATION!
More than one FD
-
query
-
simple functional dependencies
is a directed graph: strong connected components induce a preorder
on variables.
- Branching Algorithm + Unit propagation following
runs in time
!
“DPLL is worst-case optimal”!
Wrap up
- Worst-case optimality is a cute concept!
- Simple algorithm achieves it with a simple analysis
- This is roughly DPLL (exhaustive) with static ordering.
How far can we push this and remain worst case optimal?
- What about non simple functional dependencies?
- “Statistical” constraints (as maintained by DBMS)
- …
Les slides auxquelles vous avez échappé
Degree Constraints
A degree constraint is a constraint
where
.
A relation
verifies the constraint if
- Cardinality constraint = degree constraint with
.
- Functional dependency = degree constraint with
.
Acyclic Degree Constraints
set of degree constraints.
- :
vertices are the variables and
if
and
for some
.
- If
is acyclic, then let
be a topological sort of
.
Then
Our algorithm is worst case optimal wrt
(as long as we follow
).