Looking Forward to Postgres 19: Query Hints<br>Blog Home<br>Looking Forward to Postgres 19: Query Hints

Shaun Thomas|June 5, 2026

Well, the world has officially ended. Peter Venkman from Ghostbusters was right all along, and we'll soon be experiencing "human sacrifice, dogs and cats living together, mass hysteria!" Pack it in everybody; we had a great run. The feature freeze of Postgres 19 includes the one feature many claimed would never see the light of day: query hints. I guess "never say never" is pretty good advice.<br>OK, so they're not technically called hints. The Postgres community would never be so pedestrian. Instead, Postgres 19 introduces two new contrib modules: pg_plan_advice and pg_stash_advice. It's "plan advice" you see. Totally different thing.<br>An occasion this monumental deserves a bit more fanfare than simply describing the feature. So let's begin with a walk through one of the longest-running arguments in Postgres history.<br>A Brief History of "Never"<br>The Postgres community's position on query hints has been, shall we say, firm. The official wiki page on the subject states it plainly:<br>"We are not interested in implementing hints in the exact ways they are commonly implemented on other databases. Proposals based on "because they've got them" will not be welcomed."<br>Fair enough. The wiki goes on to list six solid reasons hints are problematic:<br>They create maintenance nightmares.

They break on upgrades.

They discourage root-cause analysis.

They scale poorly.

The optimizer is usually smarter than you think.

They actually impede planner improvements because users stop reporting bugs.

Yeah, that sounds about right. And for years, that was the end of the discussion. Postgres doesn't do hints. Go fix your statistics. Next topic, please.<br>But behind the scenes, the debate was never quite so settled. Back in late 2010, a legendary thread erupted on the pgsql-performance mailing list that raged on for several months and captured nearly every available sentiment. It started innocuously enough as a complaint about slow COUNT(*) queries, veered through Oracle comparisons, and somehow spiraled into a full-blown existential crisis about whether Postgres needed hints.<br>Robert Haas, threw the first real punch:<br>"I think it's just dumb to say we don't want hints. We want hints, or at least many of us do. We just want them to actually work, and to not suck."

He went further, arguing that Postgres needed to give DBAs an escape hatch for the edge cases:<br>"We should be willing to provide a way for those people to not get fired when they hit the 0.1% of queries that can't be fixed using existing methods."

It's hard to argue with "please don't let people get fired."<br>The legendary Tom Lane chimed in with similar sentiments:<br>"I haven't seen a hinting scheme that didn't suck... I don't say that there can't be one."

In doing so, he effectively left the door open just a crack.<br>Kevin Grittner later observed a rather obvious paradox in the anti-hint argument:<br>"Even those most ostensibly opposed to hints have been known to post that they would rather not have the optimizer recognize two logically equivalent constructs and optimize them the same because they find the current difference ‘useful to coerce the optimizer’ to choose a certain plan. That's implementing hints but refusing to document them."

Was he wrong? How many of us have toggled enable_seqscan to off to force an index scan? Or thrown an OFFSET 0 into a subquery to prevent the planner from flattening it? Or wrapped a materialized CTE around something just to create an optimization fence? These are hints in all but name, with coarse knobs available only to seasoned experts. We were only pretending to eschew hints.<br>Josh Berkus, one of the more vocal anti-hint advocates, drew a clear line in the sand:<br>"Any hint which gets coded into the actual queries becomes a massive maintenance and upgrade headache thereafter."

But even he wasn't against all forms of planner override. His position was against the Oracle model of embedding them in SQL comments. His preferred hierarchy was GUC cost parameters first, then cost parameters on database objects, then new statistical metadata, and query hints only as a desperate last resort. That's actually a reasonable action plan, but Postgres has always lacked that final option.<br>The third-party pg_hint_plan extension eventually filled the gap for many users, borrowing Oracle's comment-based hint syntax. It worked, more or less, and the urgency to add hints to the core quietly dissipated. Or so we thought.<br>By Any Other Name<br>So what changed? Well, for one thing, the person who built these modules is none other than Robert Haas. Fifteen years later after that epic thread, he's the author of both pg_plan_advice and pg_stash_advice. Say what you will, but the man plays the long game.<br>Haas didn't just slap Oracle-style hints onto Postgres and call it a day. He was deeply embroiled in the controversy from the very beginning, and knew all...