How a missing ANALYZE call turned a seconds-long SQL insert into a 25-minute freeze

A developer building a star-schema data warehouse on PostgreSQL using the Brazilian Olist e-commerce dataset found that loading 112,647 rows into a fact table took over 25 minutes instead of seconds. The root cause was not corrupt data or faulty SQL, but stale table statistics: because dimension tables were populated within the same uncommitted transaction, PostgreSQL had no accurate statistics for them and mistakenly assumed they were empty. This led the query planner to choose an inefficient Nested Loop with Sequential Scan, generating billions of comparisons across all rows. Running ANALYZE on each dimension table before loading the fact table updated the statistics mid-transaction, prompting the planner to switch to a Hash Join and reducing load time to seconds. The case highlights that PostgreSQL's query optimizer relies entirely on statistical models, and feeding it inaccurate table-size data silently produces disastrously slow execution plans.