[ 
https://issues.apache.org/jira/browse/FLINK-39340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Metzger updated FLINK-39340:
-----------------------------------
    Component/s: Table SQL / Planner

> Transform binary multi join back to regular join
> ------------------------------------------------
>
>                 Key: FLINK-39340
>                 URL: https://issues.apache.org/jira/browse/FLINK-39340
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table SQL / Planner
>            Reporter: Dmitriy Linevich
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: image-2026-03-27-13-33-32-140.png
>
>
> It has been observed that multi-join optimization leads to performance 
> regressions when the multi join has only two inputs.
> !image-2026-03-27-13-33-32-140.png!
> *Cluster information (through docker):*
>  * Job manager has 1 cpu and 4gb memory
>  * Task manager has 2 cpu and 4gb memory
> *Flink Configuration:*
> {code:java}
> jobmanager.rpc.address: jobmanager
> parallelism.default: 1
> pipeline.max-parallelism: 24
> taskmanager.memory.process.size: 3900m
> taskmanager.numberOfTaskSlots: 1
> process.working-dir: /data/flink-tmp
> execution.checkpointing.dir: file:///data/flink-checkpoints
> execution.checkpointing.incremental: true
> execution.checkpointing.interval: 3min
> execution.checkpointing.mode: EXACTLY_ONCE
> execution.checkpointing.unaligned.enabled: true
> execution.checkpointing.local-backup.enabled: true
> execution.checkpointing.checkpoints-after-tasks-finish.enabled: false
> execution.checkpointing.tolerable-failed-checkpoints: 20
> state.backend.type: rocksdb
> table.exec.mini-batch.enabled: true
> table.exec.mini-batch.allow-latency: 2s
> table.exec.mini-batch.size: 50000
> table.exec.async-state.enabled: false
> table.optimizer.multi-join.enabled: false
> pipeline.object-reuse: true {code}
> *Nexmark config:*
> {code:java}
> nexmark.workload.suite.100m.events.num: 100000000
> nexmark.workload.suite.100m.tps: 1000000
> nexmark.workload.suite.100m.queries: 
> "q0,q1,q2,q3,q4,q5,q7,q8,q9,q10,q11,q12,q13,q14,q15,q16,q17,q18,q19,q20,q21,q22,q23"
> nexmark.workload.suite.100m.queries.cep: "q0,q1,q2,q3"
> nexmark.workload.suite.100m.warmup.duration: 0s
> nexmark.workload.suite.100m.warmup.events.num: 0
> nexmark.workload.suite.100m.warmup.tps: 0
> nexmark.metric.monitor.delay: 10s   {code}
>  
> *As a result:*
>  * Q4 - 17% regression
>  * Q9 - 17% regression
>  * mini-batch optimization for regular join, but not for multi join
>  * window mofication for regular join, but not for multi join (Q5)
>  
> *Suggestions:*
>  # Add rule (BinaryMultiJoinToJoinRule) after multi join, that will transform 
> multi join with 2 inputs back to regular join
>  # Modify JoinToMultiJoinRule, it shouldn't to generate MultiJoin with 2 
> inputs



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to