feat(streaming): introduce cache policy for hash join

[yuhao-su]

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.

What's changed and what's your intention?

PLEASE DO NOT LEAVE THIS EMPTY !!!

Previously our hash join executor only populate cache on reading a join key. Now we allow users to specify whether to populate cache on read or on both read an write.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

To populate cache on read (default setting) use the following statement:

SET RW_STREAMING_HASH_JOIN_POLICY TO OnRead;

To read cache on both read and write use the following statement:

SET RW_STREAMING_HASH_JOIN_POLICY TO OnReadWrite;

Release note

Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.

Refer to a related PR or issue link (optional)

[codecov]

Codecov Report

Merging #3983 (30b06c8) into main (66e37d8) will decrease coverage by 0.00%.
The diff coverage is 73.68%.

@@            Coverage Diff             @@
##             main    #3983      +/-   ##
==========================================
- Coverage   73.88%   73.88%   -0.01%     
==========================================
  Files         828      828              
  Lines      117044   117143      +99     
==========================================
+ Hits        86481    86551      +70     
- Misses      30563    30592      +29     

Flag	Coverage Δ
rust	73.88% <73.68%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/stream/src/executor/mod.rs	53.70% <ø> (ø)
src/stream/src/from_proto/hash_join.rs	0.00% <0.00%> (ø)
src/common/src/session_config/mod.rs	31.41% <25.00%> (-0.54%)	⬇️
src/stream/src/executor/managed_state/join/mod.rs	87.62% <54.16%> (-4.56%)	⬇️
src/common/src/session_config/config_types.rs	86.41% <86.41%> (ø)
...ontend/src/optimizer/plan_node/stream_hash_join.rs	91.35% <100.00%> (+0.34%)	⬆️
src/stream/src/executor/hash_join.rs	97.02% <100.00%> (+<0.01%)	⬆️
src/frontend/src/expr/literal.rs	91.20% <0.00%> (-1.10%)	⬇️
src/common/src/types/ordered_float.rs	29.10% <0.00%> (+0.19%)	⬆️
... and 1 more

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[fuyufjh]

1. IIUC, your goal is to save a write, but actually since there could be more than 1 rows in a join entry, either OnRead or OnReadWrite needs to use a read to populate a join entry entirely, so I didn't see any difference. Even worse, if the join is between a fact table and a dimension table, populating cache on the fact table side is likely to be useless, because there are very few changes on the dimension table side.
2. I don't like the idea of configurable RW_STREAMING_HASH_JOIN_POLICY because users must never understand these internal details and nobody will use this config in the future. Please just select a generally good policy and remove others.

[yuhao-su]

Preliminary benching (tpch q12) shows both policy produced similar result. However we are currently facing a compactor OOM issue that causes performance deterioration within 5 min. I will bench it later after #3921 solved.

[github-actions]

This PR has been open for 60 days with no activity. Could you please update the status? Feel free to ping a reviewer if you are waiting for review.

[lmatz]

Will this PR be part of #5395 or #5395 will make this PR obsolete?

[yuhao-su]

Will this PR be part of #5395 or #5395 will make this PR obsolete?

No. They are not related.

[TennyZhuang]

Close due to outdated and controversies.