7 ms·

> I'm not sure about Postgres Not possible. It’s explicitly a non-goal, sub-optimal plans are considered a bug to be fixed, you can’t even force the use of an

> I'm not sure about Postgres Not possible. It’s explicitly a non-goal, sub-optimal plans are considered a bug to be fixed, you can’t even force the use of an index. To their credit, the Postgres query planner is amazing and does generally work very well that you don’t need forcing indexes or plans. But that’s little comfort when it does not and you have a production incident on your hands Edit: I think RDS Aurora Postgres does let you have managed query plans

barrkel 1y ago
It's not really true. There are many session-scoped flags you can set which influence planner behavior, and sometimes toggling them for a specific query is what gets you through. More often, judicious use of CTEs as an optimization barrier (materialized CTE in moderrn versions) is useful to force execution order. I like that Postgres has a lot of tools at its disposal for executing queries. But you can't rely on it for data even with modest scale. It's rare that it does a good job with interesting queries.
- williamdclt 1y ago
  I think we’re saying the same thing: you can’t force PG to a plan or an index, you can only change your query in hope it gets the hint. Even session scoped flags are a really coarse tool, don’t guarantee you’ll get the plan you want and it might unexpectedly impact other queries in the session. Materialised CTE are one of the only tools that give real control, but an optimisation barrier is often the opposite of what you want
atsjie 1y ago
> the Postgres query planner is amazing Let's agree to disagree. It's becoming too complex, too unpredictable. Every query and variable becomes a surprise in production. It's too smart for its own good.
- williamdclt 1y ago
  We don’t entirely disagree tbh. But having to work with MySQL now, I find I’m more surprised by how bad it is than I am by Postgres being too smart for its own good. I dont love everything about Postgres at all, but I always end up thinking it’s the least bad option

barrkel 1y ago

It's not really true. There are many session-scoped flags you can set which influence planner behavior, and sometimes toggling them for a specific query is what gets you through. More often, judicious use of CTEs as an optimization barrier (materialized CTE in moderrn versions) is useful to force execution order. I like that Postgres has a lot of tools at its disposal for executing queries. But you can't rely on it for data even with modest scale. It's rare that it does a good job with interesting queries.

williamdclt 1y ago
I think we’re saying the same thing: you can’t force PG to a plan or an index, you can only change your query in hope it gets the hint. Even session scoped flags are a really coarse tool, don’t guarantee you’ll get the plan you want and it might unexpectedly impact other queries in the session. Materialised CTE are one of the only tools that give real control, but an optimisation barrier is often the opposite of what you want

atsjie 1y ago

> the Postgres query planner is amazing Let's agree to disagree. It's becoming too complex, too unpredictable. Every query and variable becomes a surprise in production. It's too smart for its own good.

williamdclt 1y ago
We don’t entirely disagree tbh. But having to work with MySQL now, I find I’m more surprised by how bad it is than I am by Postgres being too smart for its own good. I dont love everything about Postgres at all, but I always end up thinking it’s the least bad option