Shaun Thomas spent 15 years watching the Postgres community insist they would never add query hints. The post traces the history back to a 2010 mailing list thread where Robert Haas called it "just dumb" to say Postgres didn't want hints - and Tom Lane left the door open just a crack with "I haven't seen a hinting scheme that didn't suck... I don't say that there can't be one." Fifteen years later, Postgres 19 ships pg_plan_advice and pg_stash_advice. Robert Haas wrote both. pg_plan_advice is per-session: SET it before running a query and the planner constrains its search to plans that honor that advice. Ask it what it's doing and it hands you the syntax to reproduce or modify the plan. pg_stash_advice is persistent: store advice by query ID and it fires automatically every time that query runs, no manual setup each time. Shaun covers the full history, the full syntax, and why this one actually addresses the objections: 📖 hubs.la/Q04kgxm60 #postgresql #postgres #postgres19 #database #dba #opensource #queryoptimization #sql

If you've ever stared at a table that's still 138 MB after deleting 600,000 rows, you already understand the problem. Postgres doesn't return bloated space to the OS after a VACUUM - it just marks dead tuples as reusable. The only built-in ways to actually reclaim space, VACUUM FULL and CLUSTER, require an ACCESS EXCLUSIVE lock for the entire operation. On a 1TB table in a production system, that's a non-starter. So DBAs have reached for tools like pg_repack and pg_squeeze - third-party utilities that rewrite tables with minimal locking by leveraging logical decoding. They work, mostly. But they operate outside the core engine's safety guarantees, and that's enough to make conservative shops nervous. Postgres 19 may change the calculus entirely. The new REPACK command brings this functionality into the core engine, with a CONCURRENTLY option that holds an ACCESS EXCLUSIVE lock only during the brief final swap - not for the entire rewrite. Shaun Thomas walks through the full demo: 138 MB down to 52 MB, space genuinely returned to the OS. There's also a USING INDEX option that replaces CLUSTER, reordering rows physically to match an index. In his benchmark, that dropped a query from 3,300 buffer reads to 49, and execution time from 3ms to 0.6ms. Worth noting: REPACK CONCURRENTLY isn't MVCC-safe in a narrow edge case (transactions that have a snapshot open but haven't yet touched the table). Shaun explains when that matters and when it doesn't. Postgres 19 is still in development, so this could still change. But if it ships, it'll be one of the more practically useful additions for anyone running large, write-heavy databases. Read the full post: hubs.la/Q04jqCKS0 #PostgreSQL #Postgres19 #DatabaseEngineering #DBA #OpenSource #Postgres #DatabasePerformance