Baymine opened a new issue, #65899: URL: https://github.com/apache/doris/issues/65899
### Description When a table (Olap or external: Hive/Iceberg/etc.) has not been analyzed, its row count is propagated as `UNKNOWN_ROW_COUNT` (-1). `StatsCalculator` clamps this to 1 row so the cost model can keep working, but `JoinUtils.checkBroadcastJoinStats` then sees "1 row" and picks the table as the broadcast join build side. For a large un-analyzed table this materializes the full table on every BE node and OOMs. ### Steps to reproduce 1. Create a large table and do **not** run `ANALYZE`. 2. Join it against another table with a session that allows broadcast joins. 3. Observe the planner picks a broadcast join; runtime OOMs. ### Expected behavior The optimizer should refuse broadcast when the build-side row count was clamped from unknown, falling back to a shuffle join. ### Actual behavior Broadcast join is chosen, leading to OOM. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
