You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For "tick/tick" join, we'd like to minimize memory pressure by persisting only one side (hopefully the small side), and probing with the other. i.e. a traditional (asymmetric) Hash Join. We achieve this by having a stratum boundary on the "build" side of the join.
Note that this doesn't make sense if both sides have "static" duration, because then we'd need to materialize it both sides anyway across ticks to ensure we join old (before this tick) and new (in this tick) tuples across both sides. (i.e. it's a bimorphism).
HOWEVER, a one-sided static/tick join does make sense. It can be done by simply persisting the static side into a persist_keyed, and streaming the tick side to probe it -- this is essentially a morphism, not a bimorphism -- ie. there's no question of joining old and new.
The text was updated successfully, but these errors were encountered:
For "tick/tick" join, we'd like to minimize memory pressure by persisting only one side (hopefully the small side), and probing with the other. i.e. a traditional (asymmetric) Hash Join. We achieve this by having a stratum boundary on the "build" side of the join.
Note that this doesn't make sense if both sides have "static" duration, because then we'd need to materialize it both sides anyway across ticks to ensure we join old (before this tick) and new (in this tick) tuples across both sides. (i.e. it's a bimorphism).
HOWEVER, a one-sided static/tick join does make sense. It can be done by simply persisting the static side into a
persist_keyed
, and streaming the tick side to probe it -- this is essentially a morphism, not a bimorphism -- ie. there's no question of joining old and new.The text was updated successfully, but these errors were encountered: