Joins

Table of Contents

Cross Joins

Referencing two tables results in a CROSS JOIN.

The result is computed by creating every possible combination (Cartesian Product) of their rows (t1 * t2 * t3 * tn) and then applying the given query operation on it (WHERE clause, SELECT list, ORDER BY clause, …):

  1. cr> select articles.name as article, colors.name as color, price
  2. ... from articles cross join colors
  3. ... where price > 5000.0
  4. ... order by price, color, article;
  5. +------------------------------+---------------+----------+
  6. | article | color | price |
  7. +------------------------------+---------------+----------+
  8. | Infinite Improbability Drive | Antique White | 19999.99 |
  9. | Infinite Improbability Drive | Gold | 19999.99 |
  10. | Infinite Improbability Drive | Midnight Blue | 19999.99 |
  11. | Infinite Improbability Drive | Olive Drab | 19999.99 |
  12. | Starship Titanic | Antique White | 50000.0 |
  13. | Starship Titanic | Gold | 50000.0 |
  14. | Starship Titanic | Midnight Blue | 50000.0 |
  15. | Starship Titanic | Olive Drab | 50000.0 |
  16. +------------------------------+---------------+----------+
  17. SELECT 8 rows in set (... sec)

Cross Joins can be done explicitly using the CROSS JOIN statement as shown in the example above, or implicitly by just specifying two or more tables in the FROM list:

  1. cr> select articles.name as article, colors.name as color, price
  2. ... from articles, colors
  3. ... where price > 5000.0
  4. ... order by price, color, article;
  5. +------------------------------+---------------+----------+
  6. | article | color | price |
  7. +------------------------------+---------------+----------+
  8. | Infinite Improbability Drive | Antique White | 19999.99 |
  9. | Infinite Improbability Drive | Gold | 19999.99 |
  10. | Infinite Improbability Drive | Midnight Blue | 19999.99 |
  11. | Infinite Improbability Drive | Olive Drab | 19999.99 |
  12. | Starship Titanic | Antique White | 50000.0 |
  13. | Starship Titanic | Gold | 50000.0 |
  14. | Starship Titanic | Midnight Blue | 50000.0 |
  15. | Starship Titanic | Olive Drab | 50000.0 |
  16. +------------------------------+---------------+----------+
  17. SELECT 8 rows in set (... sec)

Inner Joins

Inner Joins require each record of one table to have matching records on the other table:

  1. cr> select s.id, s.table_name, t.number_of_shards
  2. ... from sys.shards s, information_schema.tables t
  3. ... where s.table_name = t.table_name
  4. ... and s.table_name = 'employees'
  5. ... order by s.id;
  6. +----+------------+------------------+
  7. | id | table_name | number_of_shards |
  8. +----+------------+------------------+
  9. | 0 | employees | 4 |
  10. | 1 | employees | 4 |
  11. | 2 | employees | 4 |
  12. | 3 | employees | 4 |
  13. +----+------------+------------------+
  14. SELECT 4 rows in set (... sec)

Left Outer Joins

Left outer join returns tuples for all matching records of the left and right relation like Inner join. Additionally it returns tuples for all other records from left that don’t match any record on the right by using null values for the columns of the right relation:

  1. cr> select e.name || ' ' || e.surname as employee, coalesce(d.name, '') as manager_of_department
  2. ... from employees e left join departments d
  3. ... on e.id = d.manager_id
  4. ... order by e.id;
  5. +--------------------+-----------------------+
  6. | employee | manager_of_department |
  7. +--------------------+-----------------------+
  8. | John Doe | Administration |
  9. | John Smith | IT |
  10. | Sean Lee | |
  11. | Rebecca Sean | |
  12. | Tim Ducan | |
  13. | Robert Duval | |
  14. | Clint Johnson | |
  15. | Sarrah Mcmillan | |
  16. | David Limb | |
  17. | David Bowe | |
  18. | Smith Clark | Marketing |
  19. | Ted Kennedy | |
  20. | Ronald Reagan | |
  21. | Franklin Rossevelt | |
  22. | Sam Malone | |
  23. | Marry Georgia | |
  24. | Tim Doe | Human Resources |
  25. | Tim Malone | Purchasing |
  26. +--------------------+-----------------------+
  27. SELECT 18 rows in set (... sec)

Right Outer Joins

Right outer join returns tuples for all matching records of the right and left relation like Inner join. Additionally it returns tuples for all other records from right that don’t match any record on the left by using null values for the columns of the left relation:

  1. cr> select e.name || ' ' || e.surname as employee, d.name as manager_of_department
  2. ... from employees e right join departments d
  3. ... on e.id = d.manager_id
  4. ... order by d.id;
  5. +-------------+-----------------------+
  6. | employee | manager_of_department |
  7. +-------------+-----------------------+
  8. | John Doe | Administration |
  9. | Smith Clark | Marketing |
  10. | Tim Malone | Purchasing |
  11. | Tim Doe | Human Resources |
  12. | | Shipping |
  13. | John Smith | IT |
  14. +-------------+-----------------------+
  15. SELECT 6 rows in set (... sec)

Full Outer Joins

Full outer join returns tuples for all matching records of the left and right relation like Inner join. Additionally it returns tuples for all other records from left that don’t match any record on the right by using null values for the columns of the right relation. Additionally it returns tuples for all other records from right that don’t match any record on the left by using null values for the columns of the left relation:

  1. cr> select e.name || ' ' || e.surname as employee, coalesce(d.name, '') as manager_of_department
  2. ... from employees e full join departments d
  3. ... on e.id = d.manager_id
  4. ... order by e.id;
  5. +--------------------+-----------------------+
  6. | employee | manager_of_department |
  7. +--------------------+-----------------------+
  8. | John Doe | Administration |
  9. | John Smith | IT |
  10. | Sean Lee | |
  11. | Rebecca Sean | |
  12. | Tim Ducan | |
  13. | Robert Duval | |
  14. | Clint Johnson | |
  15. | Sarrah Mcmillan | |
  16. | David Limb | |
  17. | David Bowe | |
  18. | Smith Clark | Marketing |
  19. | Ted Kennedy | |
  20. | Ronald Reagan | |
  21. | Franklin Rossevelt | |
  22. | Sam Malone | |
  23. | Marry Georgia | |
  24. | Tim Doe | Human Resources |
  25. | Tim Malone | Purchasing |
  26. | | Shipping |
  27. +--------------------+-----------------------+
  28. SELECT 19 rows in set (... sec)

Join Conditions

CrateDB supports all operators and scalar functions as join conditions in the WHERE clause.

Example with within scalar function:

  1. cr> select photos.name, countries.name
  2. ... from countries, photos
  3. ... where within(location, geo)
  4. ... order by countries.name, photos.name;
  5. +--------------+---------+
  6. | name | name |
  7. +--------------+---------+
  8. | Eiffel Tower | France |
  9. | Berlin Wall | Germany |
  10. +--------------+---------+
  11. SELECT 2 rows in set (... sec)

Available Join Algorithms

Nested Loop Join Algorithm

The nested loop algorithm evaluates the join conditions on every record of the left table with every record of the right table in a distributed manner (for each shard of the used tables). The right table is scanned once for every row in the left table.

This is the default algorithm used for all types of joins.

Block Hash Join Algorithm

The performance of Equi-Joins#Equi-join) is substantially improved by using the Hash Join algorithm. At first one relation is scanned and loaded into a hash table using the attributes of the join conditions as hash keys. Once the hash table is build, the second relation is scanned and the join condition values of every row are hashed and matched against the hash table.

In order to built a hash table even if the first relation wouldn’t fit into the available memory, only a certain block size of a relation is loaded at once. The whole operation will be repeated with the next block of the first relation once scanning the second relation has finished.

This optimisation cannot be applied unless the join is an INNER join and the join condition obeys the following rules:

  • contains at least one EQUAL operator
  • contains no OR operator
  • every argument of a EQUAL operator can only references fields from one relation

The Hash Join algorithm is faster but has a bigger memory footprint. As such it can explicitly be disabled on demand when memory is scarce using the session setting enable_hashjoin:

  1. SET enable_hashjoin=false

Limitations

  • Joining more than 2 tables can result in execution plans which perform poorly as there is no query optimizer in place yet.