Legend — Interpreting Query Plans

Query Plans are rendered in a standard format that unifies the plans across engines.

Since Logical Plans are mostly pointless from a point of comparing capability, we are focused on the actual, physical plan being executed by the entire (since that is what you measure as useful functionality)

Query Plan Nodes
Node	Description
TABLE	The scanning or seek of a table. SCAN - The table was scanned - total rows visited (as reported by the engine) are rendered as actual. SEEK - Some kind of indexing structure was used to find rows matching a filter. Total rows retrieved from the seek are rendered If a WHERE is present, it means the query engine was able to push down a filter.
JOIN	A join operator along with its type HASH — Includes hashes incrementally populated via looping LOOP — Includes both index seeking and index scanning MERGE CROSS— — Joins without filters or filters that are not served by any hash or loop strategy. The plan is rendered as a tree with the convention that the rightmost child the probe or lookup side in join. In HASH JOIN - Rightmost child is the build side In HASH JOIN - Right child is the side being seeked
SORT	Any sort operation leading up to WINDOW AGGREGATE , AGGREGATE, MERGE JOIN or just the side effect of an `ORDER BY` in the code
GROUP BY	Aggregation done directly with `GROUP BY` or indirectly via `DISTINCT`. The strategy is postfixed to the aggregate HASH - A hash table is used for aggregation SORT — A sorted input stream is used. There will be a SORT node earlier in the plan
PROJECT	Any projection of data that changes either column count or calculates new expressions
FILTER	An operator removing rows from the incoming stream along with a description of what is removed.