cgivre commented on pull request #2289: URL: https://github.com/apache/drill/pull/2289#issuecomment-897109218
> @vvysotskyi Of course it depends what is feasible for Drill, given its current APIs, users, and code base. > > But I introduced Calcite's model of adapters and am still a big believer. (Indeed I tried to convince Drill to use Calcite's model in the early days.) I observed that if you build a simple adapter that supports scan, you have to add another parameter for filter, a way to handle rejected filters (or parts of filters), add another parameter to push down expressions and project columns (and handle rejected expressions), and it becomes exponentially more complex as you add additional operations (aggregate, join, sort, limit). > > So I proposed the model where you write rewrite rules, each of which matches a particular relational operator. The rules tend to compose fairly well. > > Maybe Drill could keep its existing Mongo adapter but also support generic Calcite adapters (powered by Calcite rewrite rules). Then Drill could pull in Calcite's Mongo adapter. If there are use cases that Calcite's Mongo adapter does not handle, they could be dealt with as Calcite bugs. @julianhyde Thanks for the response! @vvysotskyi One other thing to consider is that Drill needs these rules for query planning and parallelization. From my recollection, that was the major challenge in using the Calcite adapters as written. IMHO it would be great if we could find a way to accomplish both goals using the Calcite adapters. -- 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: dev-unsubscr...@drill.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
