Parallel Join Ordering

Faculty of Computer ScienceDatabase and Software Engineering Group

Parallel Join Ordering

Andreas Meister

Advanced Topics in Databases, 2019/April/05Otto-von-Guericke University of Magdeburg

Andreas Meister | Parallel Join Ordering

Why do we need query optimization?


SQL - TPC-H - Query 5SELECT N_NAME, SUM(L_EXTENDEDPRICE*(1-L_DISCOUNT))FROM CUSTOMER, ORDERS, LINEITEM,

SUPPLIER, NATION, REGIONWHERE C_CUSTKEY = O_CUSTKEY AND L_ORDERKEY = O_ORDERKEY

AND L_SUPPKEY = S_SUPPKEYAND C_NATIONKEY = S_NATIONKEYAND S_NATIONKEY = N_NATIONKEYAND N_REGIONKEY = R_REGIONKEYAND R_NAME = ’ASIA’AND O_ORDERDATE >= ’1994-01-01’AND O_ORDERDATE < ’1995-01-01’

GROUP BY N_NAMEORDER BY REVENUE DESC

How would you execute this query?






How would you execute this query?


ChallengesSQL• Declarative (What, not how!)

Plenty options to chose from:• Operator variants (Joins: NL, BNL, Hash, Sort-Merge, ...)• Table access: Index vs Scans• Execution: Operator order• ...

Options are based on properties of database:• Data type• Data distribution• ...

Why do we not chose an option randomly?

















ChallengeBecause the efficiency depends on the choice.

0.0

200.0

400.0

600.0

800.0

1000.0

1200.0

1400.0

1600.0

1800.0

2000.0

2200.0

2400.0

2600.0

2800.0

3000.0

random query plans [sorted by runtime]

runt

ime

[ms]

Adapted from [Neumann, 2014]


How is efficiency ensured?


Query Processing - Phases

Access plan

RuntimeTranslation time

Access plan

Algebra

Algebra Code

Optimization

StandardizationL&Simplification

TranslationL&ViewLresolving

SQL-Query Result

Execution

Code-Generation

PlanLparameterization

LogicalLoptimization

PhysicalLoptimization

Cost-basedSelection

Adapted from [Saake et al., 2012]


Query Processing - Translation & View Resolving• Simplification of arithmetic expressions• Resolve sub-queries• Insertion of view definitions

CUSTOMERORDERS

LINEITEM

SUPPLIER

NATION

X

X

X

X

REGION

X

σC_CUSTKEY = O_CUSTKEY AND L_ORDERKEY = O_ORDERKEY AND L_SUPPKEY = S_SUPPKEY AND C_NATIONKEY = S_NATIONKEY AND S_NATIONKEY = N_NATIONKEY AND N_REGIONKEY = R_REGIONKEY AND R_NAME = ’ASIA’ AND O_ORDERDATE >= ’1994-01-01’ AND O_ORDERDATE < ’1995-01-01'

ɣSUM(L_EXTENDEDPRICE*(1-L_DISCOUNT));N_NAME


Query Processing - Standardization & Simplification

• Expressions:• Conjunctive normal form:(p11 ∨ · · · ∨ p1n) ∧ · · · ∧ (pm1 ∨ · · · ∨ pmn)

• Disjunktive normal form:(p11 ∧ · · · ∧ p1n) ∨ · · · ∨ (pm1 ∧ · · · ∧ pmn)

• Query: Unnesting

<Condition>

πB

R1

σ

A in

R2

R2R1

⋈A=B


Query Processing - Optimization

• Goal: Efficient query execution

• Three phases:• Logical optimization• Physical optimization• Cost-based selection

• Method: Use available information about• Data (distribution, type, · · · )• Database system (algorithms, processors, · · · )• Query (operators, restrictions, · · · )












Query Processing - Logical Optimization• Apply optimization rules

CUSTOMER

ORDERS

LINEITEM

SUPPLIER

NATIONREGION

σO_ORDERDATE >= ’1994-01-01' AND O_ORDERDATE < ’1995-01-01'

σR_NAME = ’ASIA

ɣSUM(L_EXTENDEDPRICE*(1-L_DISCOUNT));N_NAME

⋈S_NATIONKEY = N_NATIONKEY

⋈C_CUSTKEY = O_CUSTKEY

⋈L_SUPPKEY = S_SUPPKEY AND C_NATIONKEY = S_NATIONKEY

⋈L_ORDERKEY = O_ORDERKEY

⋈ N_REGIONKEY = R_REGIONKEY


Query Processing - Algorithm

• Simple optimization algorithm• Resolve complex selection predicate,

if applicable resolving of ¬ and ∨• Remove redundant operators• Pushing down selections as near as possible to the leaf• Resolve cross joins• Pushing projections in leaf direction

• Single steps will be executed in the stated order until noreplacement can be performed


Query Processing - Physical OptimizationConsider:• Storage information (Indexes, page size, · · · )• Algorithms• Processors• · · ·

CUSTOMER

ORDERS

LINEITEM

SUPPLIER

NATIONREGION

σINDO_ORDERDATE >= ’1994-01-01'

AND O_ORDERDATE < ’1995-01-01'

σRELR_NAME = ’ASIA

ɣSORTSUM(L_EXTENDEDPRICE*(1-L_DISCOUNT));N_NAME

⋈HASHS_NATIONKEY = N_NATIONKEY

⋈HASHC_CUSTKEY = O_CUSTKEY

⋈SORTL_SUPPKEY = S_SUPPKEY

AND C_NATIONKEY = S_NATIONKEY

⋈NLJL_ORDERKEY = O_ORDERKEY

⋈SORT N_REGIONKEY = R_REGIONKEY


Query Processing - Cost-Based Selection

query

span search space

equivalent plans

search strategy

"best" plan

transformation rules

cost estimations


Often combined with physical optimization


Query Processing - Plan Parametrization

Prepared Statements:• Optimize once• Execute multiple times• Configuration via variables

→ Replace variables with values


Query Processing - Code Generation• Compile query into executable code

1 4 16 64 256 1K 4K 16K 64K 256K 1M0.1

1

10

26.6

100

DBMS "X"MySQL 4.1

28.1"tuple at a time"

interpretationdominatesexecution

6M4M

MonetDB/X100

in−cache materialization

query without selection

materialization overheadmain−memory

MonetDB/MIL"column at a time"

Tim

e (s

econ

ds)

0.60

0.22Hand−CodedC Program

"vector at a time"

3.72.4

vectors start to exceedCPU cache, causingextra memory traffic

interpretationoverheaddecreases

low interpretation overhead

TPC-H Query 1 with different vector size [Zukowski et al., 2005]


Query Processing - Execution

• Planed all details• Execute the code

What could possibly go wrong?In practice:• Wrong assumptions• Bad estimates• · · ·

→ Consider runtime information to adapt query-execution




What could possibly go wrong?

In practice:• Wrong assumptions• Bad estimates• · · ·













How does the optimization work?


Cost-based Optimization

query

span search space

equivalent plans

search strategy

"best" plan

transformation rules

cost estimations


In specific: Join-Order Optimization






In which order should the join be performed?






In which order should the join be performed?


Join-Order Optimization

Why consider join-order optimization?

0.0

200.0

400.0

600.0

800.0

1000.0

1200.0

1400.0

1600.0

1800.0

2000.0

2200.0

2400.0

2600.0

2800.0

3000.0

random query plans [sorted by runtime]

runt

ime

[ms]

Adapted from [Neumann, 2014]


Join-Order Optimization - Challenge

Goal:Find an efficient join order

Challenge:• NP-complete problem• Limited time



Goal:Find an efficient join order

Challenge:• NP-complete problem• Limited time


Join-Order Optimization - Example

CUSTOMER (C) ORDERS (O) LINEITEM (L) SUPPLIER (S) NATION (N) REGION (R)

L⋈C L⋈O L⋈S L⋈N L⋈R

((L⋈S)⋈C) ((L⋈S)⋈O) ((L⋈S)⋈N) ((L⋈S)⋈R)

(((L⋈S)⋈O)⋈N)(((L⋈S)⋈O)⋈C) (((L⋈S)⋈O)⋈R)

((((L⋈S)⋈O)⋈N)⋈C) ((((L⋈S)⋈O)⋈N)⋈R)

(((((L⋈S)⋈O)⋈N)⋈C)⋈R) (((((L⋈S)⋈O)⋈N)⋈R)⋈C)

TPC-H Q5

This is not even all!


Join-Order Optimization - Example

CUSTOMER (C) ORDERS (O) LINEITEM (L) SUPPLIER (S) NATION (N) REGION (R)

L⋈C L⋈O L⋈S L⋈N L⋈R

((L⋈S)⋈C) ((L⋈S)⋈O) ((L⋈S)⋈N) ((L⋈S)⋈R)

(((L⋈S)⋈O)⋈N)(((L⋈S)⋈O)⋈C) (((L⋈S)⋈O)⋈R)

((((L⋈S)⋈O)⋈N)⋈C) ((((L⋈S)⋈O)⋈N)⋈R)

(((((L⋈S)⋈O)⋈N)⋈C)⋈R) (((((L⋈S)⋈O)⋈N)⋈R)⋈C)

TPC-H Q5

This is not even all!


Join-Order Optimization - Tree Form

Deep Trees

⋈

⋈

⋈

⋈

⋈

L

S

O

N

C

Left-Deep Trees Right-Deep Trees

⋈

⋈

⋈

⋈

⋈

L

S

O

N

C

R R


Join-Order Optimization - Tree Form

More general tree forms:

L

S

O

N

C

R

⋈

⋈

⋈

⋈

⋈

⋈⋈

⋈⋈

⋈

L S

O N C R

Zick-Zack Trees Bushy Trees



Number of equivalent options:• Left (or Right) Deep-Trees:

• n!• For 10 tables: 3.628.800

• Bushy Trees:• S(n) · n! variants

S(1) = 1

S(n) =n−1∑i=1

S(i)S(n − i)

• For 10 tables: 17.643.225.600



Number of equivalent options:• Left (or Right) Deep-Trees:

• n!• For 10 tables: 3.628.800

• Bushy Trees:• S(n) · n! variants

S(1) = 1

S(n) =n−1∑i=1

S(i)S(n − i)

• For 10 tables: 17.643.225.600


Join-Order Optimization - TopologyNumber of valid trees depends on the query topology:

r1 rnr3r2 ...

linear

r1 rnr3r2 ...

cyclic

r3r2 rn

r1

r3 ...

r2

rn

r1

star clique

...

Considering cross-joins→ clique


Join-Order Optimization - Approaches

Deterministic Randomized

Hybrid

Exhaustive search

TransformationSampling

Genetic algorithms

Greedy


Join-Order Optimization - Deterministic Approaches

• Same input→ Same output

• Greedy:• Short runtime• Simple heuristics• Neither efficiency nor optimality guaranteed

• Exhaustive Search:• Guarantee optimal results• Long runtime• Only applicable to simple queries












Join-Order Optimization - Randomized Approaches

• Same input→ Different outputs• No optimality guaranteed, but often efficient results

• Transformation:• Selection of initial result• Transformation of current result

• Sampling:• Randomly choosing candidates• Best solution is stored

• Genetic algorithms:• Selection of initial solution pool• Creating new solutions based on solution pool




















Join-Order Optimization - Hybrid Approaches

Advantages deterministic approaches:• Predictable• Ensure optimality

Advantages randomized approaches:• Suitable for complex optimization problems• Limited runtime

Hybrid approaches:

Combine both deterministic and randomized approaches


Join-Order Optimization - Approaches

Deterministic Randomized

Hybrid

Exhaustive search

TransformationSampling

Genetic algorithms

Greedy

In specific: Dynamic programming


Join-Order Optimization - Dynamic ProgrammingAlgorithm 1: DPSIZE [Selinger et al., 1979]

Input : Join query Q with n tables T = {T1, . . . ,Tn}Output: an optimal bushy join tree

1 foreach Ti ∈ T do2 optimalPlan(Ti ) = Ti ;3 for s = 2 to n do4 for sl = 1 to s − 1 do5 sr = s − sl ;6 foreach Sl ⊂ T : |Sl | = sl do7 foreach Sr ⊂ T : |Sr | = sr do8 if Sl ∩ Sr 6= ∅ then continue;9 if Sl not connected to Sr then continue;

10 optimal-left-plan = optimalPlan(Sl );11 optimal-right-plan = optimalPlan(Sr );12 current-plan = createJoinTree(optimal-left-plan,

optimal-right-plan);13 if cost(optimalPlan(Sl ∪ Sr )) > cost(current-plan) then14 optimalPlan(Sl ∪ Sr ) = current-plan ;15 return optimalPlan(T ) ;


Dynamic Programming - DPSIZE

# Tables1

T1

T2

T3

T4



# Tables1 2

T1

T2

T3

T4

...

T3,4

T1,2



# Tables1 2 3

T1

T2

T3

T4

...

T3,4

T1,2,3

...

T1,2



# Tables1 2 3 4

T1

T2

T3

T4

...

T3,4

T1,2,3

...

T1,2,3,4

T1,2,3,4

T1,2

...



• Evaluation of DPSIZE only based on number of tables→ Not only valid...:

• (T1,T2,T3) ./ (T4)• (T1,T2,T4) ./ (T3)• (T1,T3,T4) ./ (T2)• (T2,T3,T4) ./ (T1)

.., but also invalid entries are evaluated:• (T1,T2,T3) ./ (T1)• (T1,T2,T3) ./ (T2)• (T1,T2,T3) ./ (T3)• · · ·

Solution: Enumerate calculations (DPSUB)














Dynamic Programming - DPSUB

• Idea: Use integer representation of solutions

• Table Ti available→ i-th bit set• 1 ≡ (T1)• 2 ≡ (T2)• 3 ≡ (T1,T2)• 4 ≡ (T3)• 5 ≡ (T1,T3)• · · ·• 15 ≡ (T1,T2,T3,T4)


Algorithm 2: DPSUB [Vance and Maier, 1996]Input : Join query Q with n tables T = {T1, . . . ,Tn}Output: an optimal bushy join tree

1 foreach Ti ∈ T do2 optimalPlan(Ti ) = Ti ;3 for k = 2 to n do4 for S = 2k−1 + 1 to 2k − 1 do5 foreach Sl ( S do6 optimal-left-plan = optimalPlan(Sl );7 if optimal-left-plan = ∅ then continue;8 Sr = S − Sl ;9 optimal-right-plan = optimalPlan(Sr );

10 if optimal-right-plan = ∅ then continue;11 if optimal-left-plan not connected to optimal-right-plan 6= ∅ then

continue;12 current-plan = createJoinTree(optimal-left-plan, optimal-right-plan);13 if cost(optimalPlan(S)) > cost(current-plan) then14 optimalPlan(S) = current-plan ;15 return optimalPlan(2n − 1) ;



• n=2:• 3 ≡ (T1,T2)

• n=3:• 5 ≡ (T1,T3)• 6 ≡ (T2,T3)• 7 ≡ (T1,T2,T3)

• n=4:• 9 ≡ (T1,T4)• 10 ≡ (T2,T4)• 11 ≡ (T1,T2,T4)• 12 ≡ (T3,T4)• 13 ≡ (T1,T3,T4)• 14 ≡ (T2,T3,T4)• 15 ≡ (T1,T2,T3,T4)



• n=2:• 3 ≡ (T1,T2)

• n=3:• 5 ≡ (T1,T3)• 6 ≡ (T2,T3)• 7 ≡ (T1,T2,T3)




• n=2:• 3 ≡ (T1,T2)

• n=3:• 5 ≡ (T1,T3)• 6 ≡ (T2,T3)• 7 ≡ (T1,T2,T3)




• Splitting integers determines calculations• e.g. solution s 13 ≡ (T1,T3,T4):

• 1 - 12• 4 - 9• 5 - 8• · · ·

• Implementation:1 Determine the first left join partner l

(least significant bit of s using Compiler or DeBruijn)2 Determine first right join partner (s − l)3 Determine next left join partner

l = s&(l − s)4 Repeat step 2-3 until l == s



• Splitting integers determines calculations• e.g. solution s 13 ≡ (T1,T3,T4):

• 1 - 12• 4 - 9• 5 - 8• · · ·

• Implementation:1 Determine the first left join partner l

(least significant bit of s using Compiler or DeBruijn)2 Determine first right join partner (s − l)3 Determine next left join partner

l = s&(l − s)4 Repeat step 2-3 until l == s



Remember: Valid combinations based on query topology:

r1 rnr3r2 ...

linear

r1 rnr3r2 ...

cyclic

r3r2 rn

r1

r3 ...

r2

rn

r1

star clique

...

DPSUB always enumerate all combinationsFor non-cliques also unneeded combinations are evaluated


Dynamic Programming - DPCCP

• Idea: Enumerate calculations based on query

• Approach:• Enumerate tables of query in a breath-first-manner

(Avoid duplicate calculations)• Determine connected sub-graphs within query• For sub-graphs: Determine complements (joinable

connected-subgraphs)


Dynamic Programming - DPCCP

• Idea: Enumerate calculations based on query

• Approach:• Enumerate tables of query in a breath-first-manner

(Avoid duplicate calculations)• Determine connected sub-graphs within query• For sub-graphs: Determine complements (joinable

connected-subgraphs)


Algorithm 3: DPCCP [Moerkotte and Neumann, 2006]Input : Join query Q with n tables T = {T1, . . . ,Tn}Output: an optimal bushy join tree

1 foreach Ti ∈ T do2 optimalPlan(Ti ) = i ;3 csgs = enumerateCSG(Q);4 foreach Sl ∈ csgs do5 cmps = enumerateCMP(Q,Sl );6 foreach Sr ∈ cmps do7 optimal-left-plan = optimalPlan(Sl );8 optimal-right-plan = optimalPlan(Sr );9 current-plan = createJoinTree(optimal-left-plan, optimal-right-plan);

10 if cost(optimalPlan(Sl ∪ Sr )) > cost(current-plan) then11 optimalPlan(Sl ∪ Sr ) = current-plan ;12 current-plan = createJoinTree(optimal-right-plan, optimal-left-plan);13 if cost(optimalPlan(Sl ∪ Sr )) > cost(current-plan) then14 optimalPlan(Sl ∪ Sr ) = current-plan ;15 return optimalPlan(R) ;


Dynamic Programming - Overview

• DPSIZE• Good approach for simple optimization problems• Inefficient (invalid join partners), for more complex

optimization problems

• DPSUB• Good for optimizing cliques• Based on enumeration of all possible combinations,

inefficient for other topologies

• DPCCP• Only needed join pairs are evaluated based on enumeration• Enumeration poses overhead for simple optimization

problems


Problems with traditional DP Approaches

• Serial execution of calculations

• Independent calculations available

R1

R2 R3 R4

Adapted from [Han et al., 2008]

|S| = 2: R1-R2; R1-R3; R1-R4

• Current multi-core CPUs offer parallel execution

→ Parallel DP-approach needed for current hardware


Parallelized Dynamic Programming - PDPSVAIdea: Partition independent calculations [Han et al., 2008]


• QS: Qualifier set | PlanList : Optimal query execution plan• q1, · · · , q4: Qualifier for relations | P1, · · · ,P4: QS with 1, · · · , 4 relations


Algorithm 4: PDPSVA [Han et al., 2008]Input : Join query Q with n tables T = {T1, . . . ,Tn}Output: an optimal bushy join tree

1 foreach Ti ∈ T do2 optimalPlan(Ti ) = Ti ;3 for s = 2 to n do4 SSDVs = AllocateSearchSpace(S,m);5 for i = 1 to MAX_THREAD_ID do6 threadPool.SubmitJob(MutiplePlanJoin(SSDVs[i],S));7 threadPool.sync();8 MergeAndPrunePlanPartitions(S);9 for i = 1 to MAX_THREAD_ID do

10 threadPool.SubmitJob(BuildSkipVectorArray(i));11 threadPool.sync();12 return optimalPlan(R) ;


Parallelized Dynamic Programming - PDPSVA

Idea: Distribute over different threads [Han et al., 2008]



Allocation Schemata

• Search space:b s

2 c∑smallSZ=1

(|PsmallSZ | × |PS−smallSZ |)

• Total Sum Allocation:Divide the search space in m (number of threads) smallerparts and distribute them equally over the m threads



Allocation Schemata /2

• Equi-Depth Allocation:Equally distribute each (|PsmallSZ | × |PS−smallSZ |) over allthreads

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

P1 P3 thread 1

thread 2P2 P2




• Round-Robin Outer Allocation:Randomly distribute join pairs (ti , t ′j ) to thread (i mod m)

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

P1 P3 thread 1

thread 2P2 P2




• Round-Robin Inner Allocation:Randomly distribute join pairs (ti , t ′j ) to thread (j mod m)

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

(q1q4,q1q4)(q1q4,q1q3)(q1q4,q1q2)

(q1q3,q1q4)(q1q3,q1q3)(q1q3,q1q2)

(q1q2,q1q4)(q1q2,q1q3)(q1q2,q1q2)

(q4,q1q3q4)(q4,q1q2q4)(q4,q1q2q3)

(q3,q1q3q4)(q3,q1q2q4)(q3,q1q2q3)

(q2,q1q3q4)(q2,q1q2q4)(q2,q1q2q3)

(q1,q1q3q4)(q1,q1q2q4)(q1,q1q2q3)

P1 P3 thread 1

thread 2P2 P2



Storage of allocation information

• Store distribution information in the search spacedescription vector (SSDV)

• SSDV-Entry: 〈smallSZ , [stOutIdx , stBlkIdx , stBlkOff ] ,[endOutIdx ,endBlkIdx ,endBlkOff ] , outInc, inInc〉

• smallSZ: Identifier for join of (|PsmallSZ | × |PS−smallSZ |)• stOutIdx: Start index of outer tuple• stBlkIdx: Start block index• stBlkOff: Offset of inner tuple within block• endOutIdx: End index of outer tuple• endBlkIdx: End block index• endBlkOff: Offset of end inner tuple within block• outInc: Step size for outer loop• inInc: Step size for inner loop


Storage of allocation information

• Store distribution information in the search spacedescription vector (SSDV)

• SSDV-Entry: 〈smallSZ , [stOutIdx , stBlkIdx , stBlkOff ] ,[endOutIdx ,endBlkIdx ,endBlkOff ] , outInc, inInc〉

• smallSZ: Identifier for join of (|PsmallSZ | × |PS−smallSZ |)• stOutIdx: Start index of outer tuple• stBlkIdx: Start block index• stBlkOff: Offset of inner tuple within block• endOutIdx: End index of outer tuple• endBlkIdx: End block index• endBlkOff: Offset of end inner tuple within block• outInc: Step size for outer loop• inInc: Step size for inner loop


Storage of allocation information - example


• 1 Block:• Thread 1 - SSDV-Entry:{〈1, [1,1,1] , [4,1,1] ,1,1〉 , 〈2, [−1,−1,−1] , [−1,−1,−1] ,1,1〉}

• Thread 2 - SSDV-Entry:{〈1, [4,1,2] , [4,1,3] ,1,1〉 , 〈2, [1,1,1] , [3,1,3] ,1,1〉}



Algorithm 5: MultiplePlanJoin [Han et al., 2008]Input: SSDV ,S

1 for i=1 to b s2c do

2 PlanJoin(SSDV[i],S)


Parallelized Dynamic Programming - PDPSVAAlgorithm 6: PlanJoin [Han et al., 2008]

Input: ssdvElmt ,S1 smallSZ = ssdvElmt.smallSZ; largeSZ = S-smallSZ;2 for blkIdx = ssdvElmt.stBlkIdx to ssdvElmt.endBlkIdx do3 blk = blkIdx-th block in PlargeSZ ;4 〈stOutIdx , endOutIdx〉 = GetOuterRange(ssdvElmt , blkIdx);5 for to=PsmallSZ [stOutIdx ] to PsmallSZ [endoutIdx ] step by ssdvElmt.outInc

do6 〈stBlkOff , endBlkOff 〉=

GetOffsetRangeInBlk(ssdvElmt,blkIdx,offset of to);7 for ti = blk [stBlkOff ] to blk [endBlkOff ] step by ssdvElmt.inInc do8 if to.QS ∩ ti .QS 6= ∅ then9 continue;

10 if not (to.QS connected to ti .QS) then11 continue;12 Resulting plans = CreateJoinPlans(to, ti );13 PrunePlans(PS ,ResultingPlans);


Storage of allocation information - example


• 1 Block:• Thread 1 - SSDV-Entry:{〈1, [1,1,1] , [4,1,1] ,1,1〉 , 〈2, [−1,−1,−1] , [−1,−1,−1] ,1,1〉}

• Thread 2 - SSDV-Entry:{〈1, [4,1,2] , [4,1,3] ,1,1〉 , 〈2, [1,1,1] , [3,1,3] ,1,1〉}


Parallelizing problems

• Only a small amount of combinations of different join setsare valid



Skip Vector Arrays

Problem: High number of invalid combination of qualifier sets

Idea:• Increase performance by skipping unnecessary

combinations of join sets

• Store additional skipping information to efficientlydetermine the next join sets


Skip Vector Arrays

Problem: High number of invalid combination of qualifier sets

Idea:• Increase performance by skipping unnecessary

combinations of join sets

• Store additional skipping information to efficientlydetermine the next join sets


Skip Vector Arrays



Skip Vector Arrays




• Based on DPSIZE→ Same drawback invalid calculations

• Parallelization strategies for DPSUB and DPCCP needed

• Idea: Use produce-consumer-model

Producer Queue Consumer

Consumer

Consumer

Consumer

Consumer



• Based on DPSIZE→ Same drawback invalid calculations

• Parallelization strategies for DPSUB and DPCCP needed• Idea: Use produce-consumer-model

Producer Queue Consumer

Consumer

Consumer

Consumer

Consumer


Algorithm 7: DPEGENERIC [Han and Lee, 2009]Input : Join query Q with n tables T = {T1, . . . ,Tn}Output: an optimal bushy join tree

1 EnumerationBuffer Bc , Bp;2 Hash-Table Memo;3 partial_order = buildPartialOrder(R);4 e = parseCalculations(partial_order, Memo, Bp, MAX_ENUM_CNT );5 while e 6= NO_MORE_PAIR do6 switchBuffers() // Bc = Bp and Bp = Bc ;7 for i = 0 to MAX_THREAD_ID − 1 do8 threadPool.SubmitJob(GenerateQEPs(Bc ,Memo));9 e = parseCalculations(partial_order, Memo, Bp, MAX_ENUM_CNT );

10 GenerateQEPs(Bc ,Memo));11 threadPool.sync();12 return Memo(R) ;


Parallelized Dynamic Programming - DPEGENERIC

• Characteristics:• Parallel• Producer-Consumer model• Double queue (Producer + Consumer)

• Parameters:• Maximal queue size• Partial order• Enumeration (DPSIZE ,DPSUB,DPCCP)


Parallelized Dynamic Programming - DPEGENERICPartial Order: Grouping based on resulting quantifier set

(q1)q1 (q2)q2 (q3)q3 (q4)q4

(q1,q2)

q1q2(q1,q3)

q1q3(q1,q4)

q1q4(q2,q3)

q2q3(q2,q4)

q2q4(q3,q4)

q3q4

(q1,q2q3),(q2,q1q3),(q3,q1q2)

q1q2q3

(q1,q2q4),(q2,q1q4),(q4,q1q2)

q1q2q4

(q1,q3q4),(q3,q1q4),(q4,q1q3)

q1q3q4

(q2,q3q4),(q3,q2q4),(q4,q2q3)

q2q3q4

(q1,q2q3q4),(q2,q1q3q4),(q3,q1q2q4),(q4,q1q2q3),(q1q2, q3q4),(q1q3,q2q4),(q1q4,q2q3)

q1q2q3q4

Adapted from [Han and Lee, 2009]

Problem: Only few calculations are grouped together


Parallelized Dynamic Programming - DPEGENERICPartial Order: Grouping based on size of resulting quantifier set

(q1),(q2),(q3),(q4)SRQS1

(q1,q2),(q1,q3),(q1,q4),(q2,q3),(q2,q4),(q3, q4)SRQS2

(q1,q2q3),(q1,q2q4),(q1,q3q4),(q2,q3q4),(q2,q1q3),(q2,q1q4),(q3,q1q4),(q3,q2q4),(q3,q1q2),(q4,q1q2),(q4,q1q3),(q4, q2q3)

SRQS3

(q1,q2q3q4),(q2,q1q3q4),(q3,q1q2q4),(q4,q1q2q3),(q1q2,q3q4),(q1q3,q2q4),(q1q4,q2q3)

SRQS4


Problem: Only few independent calculations are available


Parallelized Dynamic Programming - DPEGENERICPartial Order: Grouping based on size of larger quantifier set

SLQS0

SLQS1

SLQS2

SLQS3

SLQS[1,0]

SLQS[1,1]

SLQS[1,2] SLQS[2,2]

SLQS[1,3]

(q1), (q2), (q3), (q4)

(q1,q2),(q1,q3),(q1,q4),(q2,q3),(q2,q4),(q3,q4)

(q1,q2q3), (q1,q2q4), (q1,q3q4),(q2,q1q3), (q2,q1q4), (q2,q3q4),(q3,q1q2), (q3,q1q4), (q3,q2q4),(q4,q1q2), (q4, q1q3), (q4, q2q3)

(q1q2,q3q4),(q1q3,q2q4),(q1q4,q2q3)

(q1,q2q3q4),(q2,q1q3q4),(q3,q2q1q4),(q4,q1q2q3)



Parallelized Dynamic Programming - DPEGENERIC• Each element in partial: own queue

B[1,0]

(q4)(q3)(q2)(q1)

B[1,1]

(q3 , q4)(q2 , q4)(q2 , q3)(q1 , q4)(q1 , q3)(q1 , q2)

B[1,2]

(q2 , q3q4)(q4 , q2q3)(q3 , q2q4)(q1 , q3q4)(q1 , q2q3)

B[2,2]

B[1,3]


• Insert calculations into corresponding queue• Consumer iterate over all available queues and pull

available calculations• Access need to be synchronized


Parallelized Dynamic Programming - DPEGENERIC• While consumer evaluate available calculations,

the producer creates new calculations• Number of calculations is predefined

B[1,0] B[1,1] B[1,2]

(q1 , q2q4)(q4 , q1q2)(q3 , q1q2)(q4 , q1q3)(q2 , q1q3)(q3 , q1q4)(q2 , q1q4)

B[2,2]

(q1q2 , q3q4)(q1q3 , q2q4)(q1q4 , q2q3)

B[1,3]

(q1 , q2q3q4)(q4 , q1q2q3)(q3 , q1q2q4)(q2 , q1q3q4)

front



Parallelized Dynamic Programming - DPEGENERIC• Sort calculations based on dependencies→ Better parallelization

B[∗, i ]

front

B[∗, i +1] B[∗, i +2]

ThreadingAcross De-pendencies

B[∗, i ]

Ta

B[∗, i +1]

Tb

B[∗, i +2]

: dependency-free entries


What happens after a thread pulled a calculation?


Parallelized Dynamic Programming - DPEGENERIC• Sort calculations based on dependencies→ Better parallelization

B[∗, i ]

front

B[∗, i +1] B[∗, i +2]

ThreadingAcross De-pendencies

B[∗, i ]

Ta

B[∗, i +1]

Tb

B[∗, i +2]

: dependency-free entries


What happens after a thread pulled a calculation?


Parallelized Dynamic Programming - DPEGENERIC• Processing similar to sequential execution:

• Fetch information of join-partners• Evaluate costs

Hash table

q1q2q3q4

MGJN

HSJN

q1q2

NLJN

q3q4

HSJN

: a MEMO entry

: a QEP node

: a hash chain

: a plan chain


• Problem: Synchronization needed


Parallelized Dynamic Programming - DPEGENERIC• Problem: Synchronization needed• Solution:

• Group calculations into equivalence classes• Link entries directly to entries of the hash table

Hash table

q1q2q3q4

earmark-and-pinned

q1q2

NLJN

q3q4

HSJN

A synchronization-freeglobal MEMO B[1,2] (m[q1q2q3],m[q2],m[q1q3])

(m[q1q2q3],m[q3],m[q1q2])

(m[q1q2q4],m[q1],m[q2q4])

(m[q1q2q4],m[q2],m[q1q4])

(m[q1q2q4],m[q4],m[q1q2])

(m[q1q3q4],m[q3],m[q1q2])

(m[q1q3q4],m[q4],m[q1q3])

B[2,2] (m[q1q2q3q4],m[q1q2],m[q3q4])

(m[q1q2q3q4],m[q1q3],m[q2q4])

(m[q1q2q3q4],m[q1q4],m[q2q3])



So what is the best approach?


Dynamic Programming - EvaluationLinear queries - simple cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20102104106108

101010121012

#Tables

Run

time

(ns)

DPSIZE DPSUB DPCCPPDPSVA DPEGENERIC


Dynamic Programming - EvaluationStar queries - simple cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20102104106108

101010121012

#Tables

Run

time

(ns)



Dynamic Programming - EvaluationClique queries - simple cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15102104106108

101010121012

#Tables

Run

time

(ns)



Dynamic Programming - EvaluationLinear queries - complex cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20102104106108

101010121012

#Tables

Run

time

(ns)

Complex



Dynamic Programming - EvaluationStar queries - complex cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20102104106108

101010121012

#Tables

Run

time

(ns)



Dynamic Programming - EvaluationClique queries - complex cost function:

2 3 4 5 6 7 8 9 10 11 12 13 14 15102104106108

101010121012

#Tables

Run

time

(ns)



Dynamic Programming - Evaluation

• There is no best approach:• Sequential approaches good for simple problems• Parallel approaches good for complex problems

• Simple problems:• Simple cost function• Small number of tables

• Complex problems:• Complex cost function• Large number of tables












How are cost calculated?


Cost estimation

• Cost-based optimization needs cost estimations

• Cost-estimation directly influence optimization

• Challenge:• Accurate estimations• Time limit


Cost estimation

• Cost-based optimization needs cost estimations

• Cost-estimation directly influence optimization



Cost estimation• Cost-estimation directly influence optimization:

• Good estimation→ good optimization results• Bad estimations→ unpredictable optimization results


• Components:• Cardinality estimation:

• Statistics + Formulas• Histograms• Parametric approaches• Sample-based approaches

• Cost function







• Cost function







• Cost function


Cardinality estimation - Statistics + Formulas• Idea: Estimate selectivity of operators

|σF (R(R))| = sel(F ,R) · |r |

• Estimation (for interpolateable, arithmetic values) :

sel(A = v ,R) =1

valA,r

sel(A < v ,R) =v − Amin

Amax − Amin

sel(A > v ,R) =Amax − v

Amax − Amin

sel(A between v1 and v2,R) =v2 − v1

Amax − Amin

• Further cost formulas presented in [Saake et al., 2012]


Cardinality estimation - Statistics + Formulas• Idea: Estimate selectivity of operators

|σF (R(R))| = sel(F ,R) · |r |• Estimation (for interpolateable, arithmetic values) :

sel(A = v ,R) =1

valA,r

sel(A < v ,R) =v − Amin

Amax − Amin

sel(A > v ,R) =Amax − v

Amax − Amin

sel(A between v1 and v2,R) =v2 − v1

Amax − Amin

• Further cost formulas presented in [Saake et al., 2012]


Cardinality estimation - Histograms

attribute values

freq

uen

cy

real distribution

approximatedistribution



Cardinality estimation - Parametric approachesGaussian Distribution Cluster

Adapted from [Böhm et al., 2005]


Cardinality estimation - Sample-based approachesKernel density estimator

Adapted from [Heimel and Markl, 2012]


Cardinality estimation - Cost function• Input:

• Cardinality estimation• Query information• Database information

• Output: Cost estimation (artificial, time, · · · )

• Considered aspects:• Disk accesses• CPU consumption• Memory consumption• Network traffic• Execution time• Cache misses• · · ·

• Complex is not always better![Leis et al., 2015]




• Output: Cost estimation (artificial, time, · · · )• Considered aspects:

• Disk accesses• CPU consumption• Memory consumption• Network traffic• Execution time• Cache misses• · · ·





• Output: Cost estimation (artificial, time, · · · )• Considered aspects:

• Disk accesses• CPU consumption• Memory consumption• Network traffic• Execution time• Cache misses• · · ·



Is this all?


Outlook• Modern hardware• Cost estimation• New optimization approaches:

• Ant-Colony optimization• Genetic algorithms• Mixed integer linear programming• · · ·

• Further optimization problems:• Physical Database Design

• Partitioning• Index• Materialized views

• Self-Tuning• · · ·


Wrap-up

• Query Optimization

• Join-Order Optimization

• Dynamic Programming• Sequential• Parallel

• Cost estimation

There is no best approach


Wrap-up

• Query Optimization

• Join-Order Optimization

• Dynamic Programming• Sequential• Parallel

• Cost estimation

There is no best approach


References IBöhm, C., Kriegel, H.-P., Kröger, P., and Linhart, P. (2005).Selectivity Estimation of High Dimensional Window Queries via Clustering.In Advances in Spatial and Temporal Databases, volume 3633 of Lecture Notes in Computer Science, pages1–18. Springer.

Han, W.-S., Kwak, W., Lee, J., Lohman, G. M., and Markl, V. (2008).Parallelizing Query Optimization.PVLDB, 1(1):188–200.

Han, W.-S. and Lee, J. (2009).Dependency-aware Reordering for Parallelizing Query Optimization in Multi-core CPUs.SIGMOD, pages 45–58. ACM.

Heimel, M. and Markl, V. (2012).A First Step Towards GPU-assisted Query Optimization.In ADMS.

Leis, V., Gubichev, A., Mirchev, A., Boncz, P., Kemper, A., and Neumann, T. (2015).How Good Are Query Optimizers, Really?PVLDB, 9(3):204–215.

Moerkotte, G. and Neumann, T. (2006).Analysis of Two Existing and One New Dynamic Programming Algorithm for the Generation of Optimal BushyJoin Trees Without Cross Products.VLDB, pages 930–941. VLDB Endowment.


References II

Neumann, T. (2014).Engineering High-Performance Database Engines.PVLDB, 7(13):1734–1741.

Saake, G., Heuer, A., and Sattler, K.-U. (2012).Datenbanken: Implementierungstechniken.mitp-Verlag, Bonn, 3 edition.

Selinger, P. G., Astrahan, M. M., Chamberlin, D. D., Lorie, R. A., and Price, T. G. (1979).Access Path Selection in a Relational Database Management System.SIGMOD, pages 23–34. ACM.

Vance, B. and Maier, D. (1996).Rapid Bushy Join-order Optimization with Cartesian Products.SIGMOD, pages 35–46. ACM.

Zukowski, M., Boncz, P. A., Nes, N., and Héman, S. (2005).Monetdb/x100 - A DBMS in the CPU cache.IEEE Data Eng. Bull., 28(2):17–22.

Documents

Parallel Join Ordering