Looking Forward to Postgres 19: Query Hints

Postgres Finally Does the Thing Fans Swore It Never Would—and the comments are chaos

TLDR: Postgres 19 is adding a long-rejected way to steer how queries run, even if it’s dressed up under a nicer name. The community is split between relieved users saying this could save them from bad performance and traumatized veterans warning it could become an upgrade nightmare.

In a plot twist longtime database fans are treating like the end times, Postgres 19 is getting something that looks an awful lot like query hints—those little nudges that tell the software how to run a search. Officially, nobody wants to call them that, of course. They’re dressed up as “plan advice” through two new add-ons, because in tech drama, rebranding is half the battle. The original blog leans all the way in on the absurdity, joking about mass hysteria, and honestly the comments delivered exactly that energy.

The biggest mood in the thread is a mix of “finally!” and “absolutely not, I’ve seen this horror movie before.” One camp says this is a lifesaver for the weird edge cases where the database makes a bad choice and users pay the price. Commenters admitted they’ve already been using sneaky workarounds for years, with one bluntly saying “enable_nestloop = off here” and another pointing out the delicious irony that critics warn these tools can break after upgrades when, as users note, the planner itself can break after upgrades too. Ouch.

But the anti-hint trauma is very real. One commenter practically recoiled on sight, posting “Shudder” and recalling Oracle nightmares where hand-tuned directions turned into a slowdown after an update. Then there’s the fandom gossip angle: did Tom Lane, legendary hints skeptic, finally soften? That question alone turned the whole thing into a community soap opera. The result: equal parts celebration, suspicion, and nerdy popcorn.gif.

Key Points

  • PostgreSQL 19 feature freeze includes two new contrib modules, `pg_plan_advice` and `pg_stash_advice`, described as a form of plan advice rather than traditional query hints.
  • The article says PostgreSQL historically resisted optimizer hints, citing the official wiki's objections such as maintenance burden, upgrade fragility, poor scalability, and reduced planner improvement.
  • A 2010 `pgsql-performance` mailing-list discussion is presented as a major historical debate that kept the topic alive within the PostgreSQL community.
  • Robert Haas is quoted as advocating for a mechanism that helps DBAs handle rare cases where the planner cannot be fixed through existing methods.
  • The article argues that users have long relied on unofficial planner-influencing techniques like `enable_seqscan`, `OFFSET 0`, and materialized CTEs, making the new modules a formalization of existing practice.

Hottest takes

"The irony is so does the planner." — crimsonnoodle58
"man, Tom Lane has hated query hints for literally decades" — jbellis
"Shudder. Flashbacks to having to write optimiser hints in Oracle" — trollbridge
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.