[multistage] physical optimizer worker collapse when dim table is on left side of join
- Dominant language
- Java
- Stars
- 6.1k
- Forks
- 1.5k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 189
Description
## Problem
Joins where a dimension table appears on the left side can collapse to 1 worker for intermediate stages since dim tables are replicated to all servers. This can cause queries to fail with row limits in `JoinOperator` or group limits in `AggregateOperator` that would otherwise succeed in the default MSE planner.
Example query:
```
-- Dim on left: join collapses to 1 server
SET usePhysicalOptimizer=true;
SELECT d.key, f.value
FROM dim_lookup AS d
CROSS JOIN fact_large AS f
```
As a workaround, we could rewrite commutative joins so the dim table is on the right. But wanted to figure out a longer-term approach so ideally the optimizer handles this for users or at least signals to the user to rewrite the query.
## Proposed ideas
2 seems most ideal directionally. 1 would be a more targeted change.
1. **Automatically expand join workers when dim table is on the left**: Detect if the left join table is a dim table and expand the join worker set to the largest non-dim leaf worker set.
2. **Support configurable join worker selection strategy**: Support a `joinWorkerSelectionStrategy` strategy with a `LEFT_ONLY` (existing default behavior) and `LARGEST_SET` option. The `LARGEST_SET` option would be similar to 1, but generalized to always take the largest leaf worker set. Can also support a `UNION` option that takes union of both sides (similar to plain MSE today).
3. **Fail the query when the dim table is on the left side**: Not desirable, but ensures the user knows to put the table on the correct side of the join
Contributor guide
Research direction
Start in the physical optimizer's join worker selection logic and trace how replicated dimension tables affect intermediate stages. Reproduce the provided CROSS JOIN with usePhysicalOptimizer=true, then compare the worker selection with the default MSE planner and determine which proposed strategy, if any, should be supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100