[crimsonnoodle58]

> 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?

enable_nestloop = off here.

For us, joining many complex views quickly trips the planner up, so I'm really glad to see this.

> They break on upgrades.

The irony is so does the planner. I've seen queries working perfectly fine in older PG's suddenly run away in newer versions. So hints will actually bring stability.

[da_chicken]

The planner breaking on updates is common for almost all RDBMSs. They introduce optimizations that work great for 95% of customers, and some will just have queries that now act like cardinality is way off or covering indexes are missing.

[mpyne]

This issue was one of AWS's listed reasons for tending to prefer NoSQL style databases over "more performant" RDBMS, because of the more consistent worst-case performance, even if the result is worse average-case performance, which was important in their assumptions for scalability planning.

[throwatdem12311]

Every single time I’ve thought I’ve needed to try these it made it worse.

Every time Claude tries to tell me to try these, it made it worse.

Not once has it made it better for me. I’m doing materialized view refreshes with a billion rows, which is small enough maybe that this doesn’t come into play…but so far the planner knows best.

If the database can’t make it fast with just smart joins and filtering then it’s the architecture that’s a problem, not the database.

Usually the only thing I need to do is increase work_mem.

[silon42]

The hints are needed when you have a web scale / online transaction processing application, where you want to guarantee no table scan ever. Ideally, I'd want to rrun without statistics on the tables in that case (ie, no smart joins).

[Someone]

> where you want to guarantee no table scan ever.

If hints are what they say they are, they cannot guarantee anything.

And they indeed are hints. FTA: “The documentation is explicit: advice "can only produce plans the core planner considers viable." Advice only nudges the planner toward one it already considered.”

[setr]

honestly I dont want plan hinting so much as being able to ban table-scanning / nested loops / etc on specific tables, and be able to set that independent of actual table-size so I can coerce its failure in dev environments

[silon42]

+1 I agree... (except nested loops are rarely the problem, they are often the best/simplest alternative for join).

[skywhopper]

“I’ve never run into it so it can’t be a problem for other people” is an interesting take.