Part 5 of a deep dive into pg_stat_statements focuses on configuration and deallocations. The pg_stat_statements_info view exposes a deallocation counter showing how often the extension drops 5% of its hash table to make room for new entries. A 10-minute sampling window is recommended: no change is healthy, ~10 deallocations per window means losing 5% of rows per minute, and 600+ means roughly every second with serious locking overhead. The five configuration settings are covered in detail: max (requires restart, reserves memory regardless of tracking state), track (top/all/none, reload only), track_utility (on by default, turning it off instantly reduces utility-statement entries), track_planning (off by default, adds overhead), and save (restart required, default on). Beyond settings, application-level fixes matter more: avoid variable-length WHERE IN lists (use arrays instead), reduce databases per server, and avoid executing the same SQL under multiple roles, as each combination creates a separate entry.
