Comment by zbentley
1 hour ago
It’s theoretically possible to do that kind of planning on the client, but difficult and not worth it compared to letting the database do it. Especially for reporting, there’s another disadvantage: many query planners use runtime statistics from the database to build the plan; synchronizing those onto the client would be difficult and error-prone.
But why bother? If I have a thousand clients that all want to run a query, why compile the plan a thousand times (and build/distribute the local planner to all of the different clients’ platforms) when I could send a query and have the database plan and cache the query once?
For most cases I mean compiled into the client, not planned at runtime. And yes, explicitly trading away access to the live latencies and data distribution (except maybe for interactive analysts) – if you want a better query you profile and edit the client, like with any other service. Or in the JIT analogy, writing Go/Rust over JS/Java, using experience and profile-guided optimization but not realtime heuristics. Certainly this would make it easier to improve on bad plans, but that's survivorship bias, maybe I don't understand how many currently-good executions a more naive abstraction wouldn't produce.