Changing One Postgres Planner Setting From 32 to 34 Cut a Slow Query's Runtime Nearly 6,000-Fold

A developer's reporting query, built on several layers of nested views, took over two minutes to run in Postgres. The slow plan came from the planner's join_collapse_limit setting, which controls how joins are grouped before unneeded ones are removed. Testing values from 8 to 140 showed the fast and slow plans alternate in a non-monotonic pattern, with a value of 32 taking about 140 seconds and 34 taking 23.9 milliseconds. The root cause was that the planner built a costly inner join and ran it 181 times, based on a row estimate of 1 that was far off from the actual count of 181. The article then explains how views are expanded into large numbers of table references and when Postgres can remove redundant LEFT JOINs.