Hi all,
Thanks for all the feedback and suggestions so far. If there are no
further comments, we will open the voting thread tomorrow, Aug 6, 2024.
Best,
Xia
Lincoln Lee 于2024年8月1日周四 22:18写道：
> Hi Xia,
>
> Thanks for your updates! Looks good to me.
>
> Best,
> Lincoln Lee
>
>
> Xia Sun 于2024年
Hi Xia,
Thanks for your updates! Looks good to me.
Best,
Lincoln Lee
Xia Sun 于2024年8月1日周四 11:15写道：
> Hi Lincoln,
>
> Thanks for your detailed explanation. I understand your concern.
> Introducing configuration with redundant semantics can indeed confuse
> users, and the engine should minimize
Hi Lincoln,
Thanks for your detailed explanation. I understand your concern.
Introducing configuration with redundant semantics can indeed confuse
users, and the engine should minimize user exposure to these details. Based
on this premise, while also ensuring that users can choose to enable the
br
Thanks Xia for your explanation!
I can understand your concern, but considering the design of this FLIP,
which already covers compile-time inaccurate optimization for runtime
de-optimization, is it necessary to make the user manually turn off
'table.optimizer.join.broadcast-threshold' and set the
Hi Lincoln,
Thank you for your input and participation in the discussion!
Compared to introducing the 'table.optimizer.adaptive-join.enabled' option,
introducing the "table.optimizer.adaptive.join.broadcast-threshold" can
also cover the need to disable static broadcast optimization while only
ena
+1 for this useful optimization!
I have a question about the new optoin, do we really need two broadcast
join thresholds? IIUC, this adaptive broadcast join is a complement to
compile-time optimization, there is no need for the user to configure two
different thresholds (not the off represented by
Hi, Xia
Thanks for your reply. It looks good to me.
Best,
Ron
Xia Sun 于2024年7月26日周五 10:49写道：
> Hi Ron,
>
> Thanks for your feedback!
>
> -> creation of the join operators until runtime
>
>
> That means when creating the AdaptiveJoinOperatorFactory, we will not
> immediately create the JoinOpe
Hi Ron,
Thanks for your feedback!
-> creation of the join operators until runtime
That means when creating the AdaptiveJoinOperatorFactory, we will not
immediately create the JoinOperator. Instead, we only pass in the necessary
parameters for creating the JoinOperator. The appropriate JoinOpera
Hi, Xia
This FLIP looks good to me, +1.
I've two questions:
1.
>> Accordingly, in terms of implementation, we will delay the codegen and
creation of the join operators until runtime.
How are you delaying codegen to runtime, the current runtime is not SQL
planner aware. in other words, how do I
+1 for the FLIP
It's a good start to adaptively optimize the logical execution plan with
runtime information.
Thanks,
Zhu
Xia Sun 于2024年7月18日周四 18:23写道：
> Hi devs,
>
> Junrui Lee, Lei Yang, and I would like to initiate a discussion about
> FLIP-470: Support Adaptive Broadcast Join[1].
>
> In g
Hi devs,
Junrui Lee, Lei Yang, and I would like to initiate a discussion about
FLIP-470: Support Adaptive Broadcast Join[1].
In general, Broadcast Hash Join is currently the most efficient join
strategy available in Flink. However, its prerequisite is that the input
data on one side must be suffi
11 matches
Mail list logo
