clintropolis commented on PR #12636: URL: https://github.com/apache/druid/pull/12636#issuecomment-1155768076
>That said, it is worth spending time to trace exactly how we handle parameters to be sure we account for the proper flow. Dynamic parameters are handled in two places, the first by rewriting the `SqlNode` with https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/calcite/planner/SqlParameterizerShuttle.java#L40 and the second, if any of them are missed at that layer, at the `RelNode` level with https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/calcite/planner/RelParameterizerShuttle.java#L59. The PR that added them, #6974, has some additional details. > In general, there should be no reason to replan a query under normal conditions: other tools that use Calcite generally make do with a single pass. Where tools tend to plan a second time is if the planner paints itself into a corner, some global state is changed, and the planner is run a different way. (Impala used to do that.) I somewhat remember getting different results based on whether or not the parameter bindings (and more importantly, their types) were present or not when running things through the planner, but if I remember might not change the end result native query so much. But yeah, in the JDBC case the state is a bit different once the parameters have values bound to them because they now have a type. SQL over HTTP also supports dynamic parameters, but in that case the bindings come with the HTTP request, instead of after preparing the statement like in JDBC, so there is no intermediary state where we have a bunch of typeless things hanging out. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
