[
https://issues.apache.org/jira/browse/DRILL-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942155#comment-15942155
]
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_r108051767
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/SchemaTreeProvider.java
---
@@ -119,6 +127,74 @@ public SchemaPlus createRootSchema(SchemaConfig
schemaConfig) {
}
}
+
+ public SchemaPlus createPartialRootSchema(final String userName, final
SchemaConfigInfoProvider provider,
+ final String storage) {
+ final String schemaUser = isImpersonationEnabled ? userName :
ImpersonationUtil.getProcessUserName();
--- End diff --
Please move the user resolution into a method rather than duplicating the
code.
More broadly, wouldn't the answer here be a constant for any qiven query?
So, there is no reason to keep recomputing it. Can we just do it once and save
it somewhere?
Let's think. If this whole structure is for a single query, then the user
is constant and can be stored in the object itself.
Is this the only place where we need to figure out impersonation and actual
user? If not, then the setup should be done at a higher level, not in each
place where it is needed.
Perhaps we need a UserIdentity class that has the loginName and
effectiveName, where these are the same for non-impersonation, but differ for
impersonation.
> 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)
