You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most query optimizations do not take into account whether a column (or expression) is indexed.
In most cases, the optimization can make reasonable choices by simply taking into account the type of the expressions (example: constant vs parameter vs column, ...).
In some cases (especially in the case of symmetries) information coming from the model could help choose the most appropriate expression.
It is not clear how often this is relevant; most cases seem to be handled appropriately by the simpler (type-driven) heuristics.
Real-world use cases would be especially interesting to understand the tradeoff.
The text was updated successfully, but these errors were encountered:
Noting that knowing model information isn't trivial - ColumnExpression doesn't reference the IProperty it represents, and reverse-engineering that isn't trivial. At some point we may want to consider enriching our SQL tree model with more information, e.g. adding an option Property to ColumnExpression.
Yep. Noting also that for NativeAOT, we currently have trouble generating code representation for our SQL tree, since it references "detached" type mappings, and we can't easily recreate those type mappings in generated code. If we had IProperty instead, we could generate code that looks up those properties in the model. Although fully replacing type mappings by IProperty is a pretty drastic change that needs to be considered more carefully.
Most query optimizations do not take into account whether a column (or expression) is indexed.
In most cases, the optimization can make reasonable choices by simply taking into account the type of the expressions (example: constant vs parameter vs column, ...).
In some cases (especially in the case of symmetries) information coming from the model could help choose the most appropriate expression.
It is not clear how often this is relevant; most cases seem to be handled appropriately by the simpler (type-driven) heuristics.
Real-world use cases would be especially interesting to understand the tradeoff.
The text was updated successfully, but these errors were encountered: