Queries may exhibit very slow planning times if they have the following characteristics:
- references many tables and/or views with many columns
- many nested views, inline views and/or WITH-clause views
- many unions and/or unions with many operands
The slowness is due to the expensive equivalence class computation which grows exponentially in the number of "slots" in the query. Slots are roughly equivalent to column references (physical as well as virtual).
The planning timeline will show a large time spent in "Equivalence classes computed":
For example, while experimenting with inserting a single row per partition as part of ETL performance testing I noticed that queries with a large number of UNION operators spend a lot of time in computeEquivClasses().
The majority of the time is spent in HashSet.contains.
|Stack Trace||Sample Count||Percentage(%)|
Not clear what the complexity of loops in computeEquivClasses() but it is obviously inefficient.
For the attached query with 1800 UNION operators computing equivalence classes takes several minutes.
|Remove equivalence classes||Resolved|
|Only compute value transfers for materialized slots||Open||Unassigned|