[
https://issues.apache.org/jira/browse/DRILL-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942159#comment-15942159
]
ASF GitHub Bot commented on DRILL-5089:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/795#discussion_r108052368
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/ops/QueryContext.java ---
@@ -144,6 +145,25 @@ public SchemaPlus getNewDefaultSchema() {
return defaultSchema;
}
+ public SchemaPlus getPartialDefaultSchema() {
+
+ final String sessionSchemaPath = session.getDefaultSchemaPath();
+ final List<String> schemaPathAsList =
Lists.newArrayList(sessionSchemaPath.split("\\."));
+
+ final SchemaPlus rootSchema =
schemaTreeProvider.createPartialRootSchema(getQueryUserName(),
+ this, schemaPathAsList.get(0));
+
+ final SchemaPlus defaultSchema = session.getDefaultSchema(rootSchema);
+
+ if (defaultSchema == null) {
+ return rootSchema;
+ }
+ return defaultSchema;
+ }
+
+ public void addNewRelevantSchema(Set<String> storages, SchemaPlus
toExpandSchema) {
+ schemaTreeProvider.addPartialRootSchema(getQueryUserName(), this,
storages, toExpandSchema);
--- End diff --
Per a comment later on, find a good home for computing the effective user
name (with impersonation enabled). That calculation should probably be done on
the user session if the impersonation is for the life of the session, or on the
query context if the impersonation is only for the single query. (Note that if
it is only for a query, temp tables probably won't work the way we expect.)
But, doing the impersonation check in the schema tree provider is pushing
that behavior too far down into the code.
> 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)