[ https://issues.apache.org/jira/browse/DRILL-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15968517#comment-15968517 ]
Julian Hyde commented on DRILL-5089: ------------------------------------ How are you able to call {{SimpleCalciteSchema.from}}? Isn't {{SimpleCalciteSchema}} package-private? In CALCITE-1748 you ask to override a method that returns {{CalciteSchema}} but in CALCITE-911 we agreed that Drill wouldn't create your own CalciteSchema sub-classes. What has changed? Can you take a look at CALCITE-1742, and tell me how it relates to your problem? I'd rather fix Calcite's schema cache for Drill's and Phoenix's needs rather than let people drill holes in our APIs. > Skip initializing all enabled storage plugins for every query > ------------------------------------------------------------- > > Key: DRILL-5089 > URL: https://issues.apache.org/jira/browse/DRILL-5089 > Project: Apache Drill > Issue Type: Improvement > Components: Query Planning & Optimization > Affects Versions: 1.9.0 > Reporter: Abhishek Girish > Assignee: Chunhui Shi > Priority: Critical > > In a query's lifecycle, at attempt is made to initialize each enabled storage > plugin, while building the schema tree. This is done regardless of the actual > plugins involved within a query. > Sometimes, when one or more of the enabled storage plugins have issues - > either due to misconfiguration or the underlying datasource being slow or > being down, the overall query time taken increases drastically. Most likely > due the attempt being made to register schemas from a faulty plugin. > For example, when a jdbc plugin is configured with SQL Server, and at one > point the underlying SQL Server db goes down, any Drill query starting to > execute at that point and beyond begin to slow down drastically. > We must skip registering unrelated schemas (& workspaces) for a query. -- This message was sent by Atlassian JIRA (v6.3.15#6346)