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
I think we need to handle the case that a row is updated while the join key is not changed. This can be done in a separate PR, but overall I think it's a must-have enhancement
@fuyufjh I just realized that the case of a row is updated while the join key is not changed couldn't be optimized because we can't know the inner table whether has been updated. If the inner table is updated we need to delete the row from memo table and insert a row into the memo table with the latest inner table's values.
@fuyufjh I just realized that the case of a row is updated while the join key is not changed couldn't be optimized because we can't know the inner table whether has been updated. If the inner table is updated we need to delete the row from memo table and insert a row into the memo table with the latest inner table's values.
I think this behavior is up to us to define. That is, when a row changed while the join key in that row didn't change, either updating the result or not makes sense.
Considering the users chose temporal join instead of normal join, I suppose he majorly cares about the changes from outer side (fact table) rather than inner side (dim table). From this perspective, I tend to not updating the result under this case.
Originally posted by @fuyufjh in #16286 (comment)
The text was updated successfully, but these errors were encountered: