fhueske commented on code in PR #28737:
URL: https://github.com/apache/flink/pull/28737#discussion_r3596783090
##########
docs/content/docs/sql/reference/queries/joins.md:
##########
@@ -300,6 +300,74 @@ The main difference between above Temporal Table DDL and
Temporal Table Function
- The temporal table DDL can be defined in SQL but temporal table function can
not;
- Both temporal table DDL and temporal table function support temporal join
versioned table, but only temporal table function can temporal join the latest
version of any table/view.
+LATERAL SNAPSHOT Join
+--------------
+
+{{< label Streaming >}}
+
+A `LATERAL SNAPSHOT` join is a *stream enrichment* join that augments an
append-only table (the *probe* side) with the current state of an updating
table (the *build* side).
+Unlike an [event-time temporal join](#event-time-temporal-join), it does not
correlate each probe-side row with a specific historical version of the build
side.
+Instead, every probe-side row is joined with the build-side state that is
current at the time the row is processed, similar to a [processing-time
temporal join](#processing-time-temporal-join), but with well-defined behavior
at query start-up.
+
+The `LATERAL SNAPSHOT` join is designed for scenarios where the other temporal
joins are a poor fit:
+
+- The build side updates **infrequently**. An event-time temporal join relies
on continuous build-side watermarks to emit results, so a build side that
rarely advances its watermark stalls the join and lets probe-side state
accumulate. A `LATERAL SNAPSHOT` join does not stall when the build side goes
idle.
+- The application has **low-latency** requirements that are incompatible with
the watermark-induced delay of an event-time temporal join.
+- The build side has **no primary key**. Event-time and processing-time
temporal joins require the build-side primary key to appear in the equi-join
condition; a `LATERAL SNAPSHOT` join does not.
+
+The build side is wrapped in the `SNAPSHOT` table function inside a `LATERAL
TABLE` clause. Both `INNER JOIN` and `LEFT [OUTER] JOIN` are supported. The
join requires at least one conjunctive equality predicate; additional non-equi
predicates are allowed in the `ON` clause.
+
+```sql
+SELECT [column_list]
+FROM probe_table
+[LEFT] JOIN LATERAL TABLE(
+ SNAPSHOT(
+ input => TABLE build_table,
+ [ load_completed_condition => <'compile_time' | 'user_time'>, ]
+ [ load_completed_time => <timestamp_ltz>, ]
+ [ load_completed_idle_timeout => <interval>, ]
+ [ state_ttl => <interval> ])) AS s
+ON probe_table.key = s.key
Review Comment:
these are just random columns that both tables are joined on. Columns
references by equality join predicates are often called join keys. They don't
have to be defined as primary or foreign keys, but it's quite common that they
are.
I'll rename the columns to make this less confusing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
