Skip to content

Broadcast join wrongly chosen for un-analyzed tables, causing OOM #65899

Description

@Baymine

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions