> At first blush, if the API were to take a plan as input and produce an AST or null as output.
Unfortunately the classes involved are not in that great of shape for being exposed as an api, so I would be hesitant to do that.
> Another idea is to give pass the CommandContext to the API. This would allow the API to execute queries to obtain costing information - thus making the costing more dynamic.
We should differentiate the scenarios. To just obtain fresh costing information could be done with a fairly targeted enhancement. To push less to the source could also be a relatively small change. Beyond that are you primarily looking to influence the join structure?
> We should differentiate the scenarios
Sounds good. The separate scenarios are:
- Obtain costing information on a per query basis. For API modeled as tables, the costing can be heavily influenced by the particular combination of parameters so a mechanism to evaluate costing after analyzing the query structure would be nice. I imagine something similar to the way result set caching is handled in the translator.
- Pushing less to the source - What do you mean by this?
- Influencing the join structure - yes, but I'm having trouble the form this would take without getting into the middle of the planning phase.
1) Yes that is doable. A check prior to heart of join planning could give us a better idea about how to proceed.
2) Indicate that there are parts of the query that the engine should execute rather than pushing down.
3) #1 would hopefully be sufficient for this.