davidradl commented on code in PR #27099:
URL: https://github.com/apache/flink/pull/27099#discussion_r2419068448
##########
docs/layouts/shortcodes/generated/execution_config_configuration.html:
##########
@@ -129,6 +129,24 @@
<td>Boolean</td>
<td>Set whether to compact the changes sent downstream in row-time
mini-batch. If true, Flink will compact changes and send only the latest change
downstream. Note that if the downstream needs the details of versioned data,
this optimization cannot be applied. If false, Flink will send all changes to
downstream just like when the mini-batch is not enabled.</td>
</tr>
+ <tr>
+ <td><h5>table.exec.delta-join.cache-enabled</h5><br> <span
class="label label-primary">Streaming</span></td>
+ <td style="word-wrap: break-word;">true</td>
+ <td>Boolean</td>
+ <td>Whether enable the cache of delta join. If enabled, the delta
join would cache the records from remote dim table.</td>
Review Comment:
it would be useful to give some guidance in the docs as to when to switch on
caching and how to tune the left and right time values. I assume there is some
level of staleness we introduce by using the caches, we should talk about this
consideration as well. I am interested in what happens to the join results
during cache an after the cache invalidates one side after the timeout.
The Jira gives no details. I would like to see details around the motivation
behind this change, in which circumstances it is most and least useful so we
can easily see how and when this adds value.
--
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]
