2 ms·
This one is interesting. The abstraction for SQL is related to how the work gets done, not what it produces. The missing piece is for the user to be able to c
by RaftPeople 2y ago
This one is interesting.
The abstraction for SQL is related to how the work gets done, not what it produces. The missing piece is for the user to be able to control that optimization of how the work gets done, which is getting right down into the details of what SQL was abstracting in the first place.
There could be a middle ground where the user provides input about target performance and the engine uses that input during choice of execution plans.
Maybe an OPTIMIZATION clause for difficult or long running queries:
ALLOW_EXTENDED_PLAN_SEARCH=True
or
MINIMIZE_EXECUTION_TIME_FACTOR=10 (1=just do simple, 10=expend more time+space up front to reduce overall time)
- vbezhenar 2y agoUser does not want to control optimizations. User wants their queries to run fast enough. Ideally database should monitor the queries and create/remove necessary indices as needed. And some databases do that.
- RaftPeople 2y ago> User does not want to control optimizations. It's true, it would nice if the user didn't need to intervene, but unfortunately query optimization is a combinatorial problem where the engine has incomplete information causing performance problems (or cost problems if you are on Snowflake), so the user is required to intervene some percentage of the time.