> A cross join is a Cartesian product I think that's the most important detail that can't be explained visually like this. Cartesians explode the row-counts -

> A cross join is a Cartesian product I think that's the most important detail that can't be explained visually like this. Cartesians explode the row-counts - 10 rows x 10 rows is 100, not 10 or less than (which is the assumption for most people as they write joins with a primary key on at least one side). If you have a cartesian and add on the additional entry needed for the null in outers, you can explain the output of the join as a filter over that set (full outers make more sense in that model). In fact, that's a good way to think of when you see WHERE used to produce an inner join (cartesian + filter == inner). Sometime ago, I had to optimize pure cartesian joins which had a user-defined function like ON overlaps(time_range1, time_range2) and this involved a deep-dive[1] into distributing a cartesian join to parallelize the filtering. [1] - http://people.apache.org/~gopalv/xldb18/tez-xprod.pdf http://people.apache.org/~gopalv/xldb18/tez-xprod.pdf