[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.