-
|
I'm trying to join two Kafka-sourced UPSERT tables based on a range condition, but getting a "streaming nested-loop join not supported" error. Tables Query Error My use case is to dynamically categorize companies into market cap buckets where bucket definitions can change. What's the recommended pattern for range-based joins in streaming contexts? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Hi @marigov, unlike the batch world, streaming join without equi-join condition is generally inefficient and can hardly be parallelized because the two sides of join contain unbounded and continuous data set. Unlike traditional batch nested loop join, you cannot just wait for all data to arrive before doing the iteration. Therefore, RisingWave bans streaming join without equi-join condition unless one side of the join is a scalar sub-query (See https://docs.risingwave.com/processing/sql/dynamic-filters), which doesn't seem to be the case from you example. However, if one side of the join is relatively small and the change frequency is low, you can workaround the limitation by adding a dummy equi-join condition to hint the optimizer to generate a single-parallelism hash join plan for execution. Example: |
Beta Was this translation helpful? Give feedback.
-
|
Let's try this: |
Beta Was this translation helpful? Give feedback.
Let's try this: