Teradata Join Processing

Center of Excellence

Data Warehousing

Wipro Technologies

Join Processing

Rows to be joined must be on the same AMP.

For join processing, copies of some or all of the rows may have to be moved to a common AMP.

Join plans Product join. Merge join Nested join

Join Processing

General scenarios: Join column is the PI of both the tables.

Join column is PI of one of the tables.

Join column is not a PI of either of the table.

Case 1- PI of both the tables

Rows taking part in the join are already in the same AMP.

No data movement is necessary.

Rows are already in sorted order (within the block)

This is the best case scenario.

Case 2 - PI of one of the tables

One table has its rows on the target AMP.

Rows of the other table need to be redistributed to their target AMPs by the hash code of the join column value.

If the table is small optimizer may choose to duplicate the table on all AMPs

Case 3 - not a PI of either of the table

Rows of both the tables need to redistributed to their target AMPs by the hash code of the join column value.

Optimizer might choose to duplicate the smaller table on all AMPs.

This join scenario involves maximum number of data movement.

Nested Join

Optimizer choose this join strategy when An equality value for a unique index (UPI or

USI) on table 1. A join on a column of that single row to any

index on table 2. This joining uses minimum system resource

PI

PI

USI

USI

NUSI

NUSI

2 AMPs

3 AMPs

3 AMPs

4 AMPs

ALL AMPs

ALL AMPs

1 OR MORE ROWS RETURNED

1 OR MORE ROWS RETURNED

1 ROW RETURNED

1 ROW RETURNED

1 OR MORE ROWS RETURNED

1 OR MORE ROWS RETURNED

UPI , data column

USI , data column

UPI , data column

USI , data column

UPI , data column

USI , data column

data value

data value

data value

data value

data value

data value

=

=

=

=

=

=

Product Join

Most general for of join

Optimizer chooses product join in following conditions WHERE clause is missing. Join condition is not based on equality condition. Join conditions are ORed together. Table alias are incorrectly used. Optimizer determines that it is less expensive than

other join types.

Identify the smaller table duplicate it in spool on all AMPs. Join each spool row of the smaller table to every row of the larger table.

Merge Join

Commonly done when the join conditions are based on equality.

Generally more efficient than Product Join as number of row comparisons are less.

Steps Identify the smaller table. Put the qualifying rows from one or both table into spool. Move the spool rows to the AMPs based on join column

hash (if required). Sort the spool rows by join column hash value (if

necessary). Compare those rows with matching join column hash values.

Merge Join

Row Hash

Col1 Col2….

110A

110A

111B

111B

203C

203C

203C

110E

Row Hash

Col1

110A

120B

203C

210D

Example

Col1

(PK)

Col2 Col3

(FK)

100 P 600

200 Q 600

300 R 700

400 S 200

500 T 500

600 X 200

700 Y 300

800 Z 500

900 A 800

1000 B 300

2000 C 300

3000 D 300

4000 E 200

Col1 (PK)

Col2……

100 K

200 L

300 M

400 N

500 O

600 P

700 Q

800 R

Table 1 Table 2

Example

100 P 600800 Z 5001000 B 300

100 K800 R

400 S 200700 Y 3002000 C 3004000 E 200

400 N700 Q

300 R 700600 X 200900 A 800

300 M600 P

200 Q 600500 T 5003000 D 300

200 L500 O

Row Distribution Strategy 1

No distribution needed.

No sorting needed.

Join columns of both the tables are PIs. Rows involved in the join are located in the

same AMP.

Case 1 - Example

SELECT * FROM Table1 t1 INNER JOIN Table2 t2 ON t1.Col1 = t2.Col1

100 P 600800 Z 5001000 B 300

100 K800 R

400 S 200700 Y 3002000 C 3004000 E 200

400 N700 Q

300 R 700600 X 200900 A 800

300 M600 P

200 Q 600500 T 5003000 D 300

200 L500 O

Row Distribution Strategy 2

Distributing and sorting one of the table on join column row hash.

Join column is PI of one of the tables. One of the tables is already distributed on join

Column Row Hash.

Optimizer redistributes one of the tables and sort on join column row hash.

Case 2 – ExampleSELECT * FROM Table1 t1 INNER JOIN Table2 t2 ON t1.Col3 = t2.Col1

100 P 600800 Z 5001000 B 300

100 K800 R

400 S 200700 Y 3002000 C 3004000 E 200

400 N700 Q

300 R 700600 X 200900 A 800

300 M600 P

200 Q 600500 T 5003000 D 300

200 L500 O

900 A 800

100 K800 R

300 R 700

400 N700 Q

1000 B 3003000 D 300700 Y 3002000 C 300200 Q 600100 P 600

300 M600 P

600 X 200400 S 2004000 E 200800 Z 500500 T 500

200 L500 O

SPOOL

Row Distribution Strategy 3

Duplicating and sorting the smaller table on all AMPs and locally building the larger table and sorting it.

Optimizer considers this strategy if it finds redistributing a larger table is more expensive than duplicating a the smaller table.

Case 2 – Example

100 P 600800 Z 5001000 B 300

100 K800 R

400 S 200700 Y 3002000 C 3004000 E 200

400 N700 Q

300 R 700600 X 200900 A 800

300 M600 P

200 Q 600500 T 5003000 D 300

200 L500 O

1000 B 300100 P 600800 Z 500

100 K200 L300 M400 N500 O600 P700 Q800 R

400 S 2004000 E 200700 Y 3002000 C 300

100 K200 L300 M400 N500 O600 P700 Q800 R

600 X 200300 R 700900 A 800

100 K200 L300 M400 N500 O600 P700 Q800 R

3000 D 300500 T 500200 Q 600

100 K200 L300 M400 N500 O600 P700 Q800 R

SPOOL

Row Distribution Strategy 4

Duplicate the smaller table on every AMP.

Optimizer chooses this strategy the join condition is not based on equality.

Product join scenario.

Explain Facility

Provides an English translation of the steps chosen by the optimizer.

Very helpful to estimate the performance of complex queries.

Helps physical designers in their index selection by providing the execution strategy chosen by the optimizer.

Explaining the EXPLAIN

Generally EXPLAIN outputs are clear and easy to understand however it contains few phrases one needs to be familiar with. “….with no residual conditions…” : There is no residual

conditions other than the conditions used locate the row.

“..eliminating duplicates..” : DISTINCT operation being done.

“…we do a SMS…” : Set manipulations like UNION, EXCEPT are being done.

“…we do a BMSMS…” : NUSI Bit mapping being used. “…distributed by hash code to all AMPs…” “…duplicated on all AMPs…”

Statistics Optimizer needs demographic information to create best

execution plan for a query. Number of rows in the table. Row size. Number of rows per value. Index information and demographics.

Based on the statistics optimizer estimates the cost and creates the best plan.

Statistics must be collected for the columns and indexes being accessed frequently.

If Statistics are not provided, optimizer does Dynamic Sampling (Random AMP).

Questions ?