Add NEAREST join support

[martint]

Add support for NEAREST in CROSS JOIN and LEFT JOIN ... ON TRUE.

For example:

...
FROM trades
LEFT JOIN NEAREST (
    FROM quotes
    WHERE quotes.symbol = trades.symbol
    MATCH quotes.ts <= trades.ts
) ON TRUE

and

...
FROM trades
CROSS JOIN NEAREST (
    FROM quotes
    WHERE quotes.symbol = trades.symbol
    MATCH quotes.ts <= trades.ts
)

The current implementation produces a naive plan that leverages existing plan IR and operators. A more performant implementation will require custom plan nodes and a dedicated join-like operator.

CROSS JOIN plan shape:

- Project[left columns..., nearest columns...]
   - TopNRanking[ROW_NUMBER by (left_unique) order by (candidate_key)] 
       - Join[INNER on (WHERE and MATCH)] 
           - AssignUniqueId[left_unique] 
               - left input 
           - NEAREST source

LEFT JOIN ... ON TRUE plan shape:

- Project[left columns..., nearest columns...]
   - TopNRanking[ROW_NUMBER by (left_unique) order by (candidate_key)] 
       - Join[LEFT on (WHERE and MATCH)] 
           - AssignUniqueId[left_unique] 
               - left input 
           - NEAREST source

• Fixes Add support for ASOF join #21759

Release notes

(x) Release notes are required, with the following suggested text:

## General
* Add support for the `NEAREST` clause for approximate matches in joins. ({issue}`21759`)

[findepi]

This is awesome proof of concept! I am not sure the syntax is ideal from user perspective yet. I have posted syntax considerations to the issue:

• Add support for ASOF join #21759 (comment)

[martint]

@kasiafi, updated.

Also, added support for implicit ON TRUE.

[findepi]

What is implicit ON TRUE? is it only for NEAREST or all the joins?

[martint]

For all joins. It’s a similar idea to how the FROM clause is optional.

[findepi]

Why not NEAREST (relation) MATCH match?

This would make for a simpler grammar that's more familiar to users. Otherwise there will be questions why I cannot SELECT before the FROM or, why i can have WHERE but not HAVING, etc.

[martint]

You need a WHERE clause to link the left and right sides of the join. I don't think that's more familiar to users. NEAREST is nothing but a simplified (syntactic sugar for) form of:

LATERAL (
    SELECT *
    FROM <relation>
    WHERE <condition> AND left.match_column <op> right.match_column
    ORDER BY <match column>
    LIMIT 1
)

If users want to do something more complicated, they can always use the explicit form.

[findepi]

You need a WHERE clause to link the left and right sides of the join.

If we're thinking about NEAREST as a special case of a join, we could use a syntax that describes that.

if we're thinking about NEAREST MATCH as a way to find the best match, then WHERE clause is no special.
The lateral subquery could be just values, some aggregation or something else. The MATCH is special, the WHERE is not. I don't see why grammar would make WHERE special.

[martint]

NEAREST is not a special kind of join. It is a table-like relation, similar in spirit to UNNEST or JSON_TABLE, whose job is to return the row from its input that is closest to some anchor expression from the left side. In that model, MATCH is special because it defines what "closest" means. WHERE is not special, but it's what's needed for the function to constrain the candidate set based on some row on the left side of the join.

[kasiafi]

Also, added support for implicit ON TRUE.

Is there implicit ON TRUE? I think that implicit join takes no criteria.
Also, we could support INNER JOIN ON TRUE.

[findepi]

For all joins. It’s a similar idea to how the FROM clause is optional.

Snowflake's JOIN has optional ON clause, and I remember I had some problems with grammar ambiguities (which JOIN does this ON pertain to?) when working on antlr grammar for Snowflake. I don't remember the specifics though.

[martint]

Is there implicit ON TRUE? I think that implicit join takes no criteria.
Also, we could support INNER JOIN ON TRUE.

Right, what I meant by implicit was "implicit condition". I'll add support for implicit joins (i.e., SELECT ... FROM t, NEAREST(...))

[martint]

... some problems with grammar ambiguities ...

Let me look into that. In the meantime, I'll back out that extension. We can re-introduce it later to improve usability.

[kasiafi]

LGTM % LogicalPlanner test and the question about correlation in WHERE.