[
https://issues.apache.org/jira/browse/DRILL-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637758#comment-14637758
]
Mehant Baid commented on DRILL-3500:
------------------------------------
After having some offline discussion with Jacques, we decided to first evaluate
the existing planning contexts to make sure the new "context" is needed and
cannot be merged with one of the existing classes.
1. QueryContextInformation/ContextInformation: This class contains information
about the query start state for instance query start time, query timezone,
default schema. This is created in QueryContext and propagated to the
individual fragments where it will ultimately be consumed by UDF's as an
Inject.
2. PlannerSettings: This class essentially exposes session options related to
the planner and has a bunch of helper methods to get frequently used options.
3. QueryContext: This is the umbrella context that contains all information
needed for the planning phase (PlannerSettings and QueryContextInformation are
part of this class).
4. OptimizerRulesContext (newly proposed): This currently exposes state like
BufferAllocator, FunctionRegistry etc needed to write optimizer rules (for
interpreter based execution) which is present in the QueryContext . Common
interface to Drill internal rules and storage plugin specific rules.
With the existing structure of classes OptimizerRulesContext does not really
fit well with the other classes. Because conceptually the rules need a
'QueryContext' and this simply provides a interface on top of QueryContext for
encapsulation.
We could also go down the route of making PlannerSettings more heavy weight and
using it as PlannerContext. Couple of my concerns with this approach is that
for encapsulation purposes we would still need to add an interface on top of it
since we are exposing this to storage plugins. PlannerContext and QueryContext
will share a bunch of object references which seems unnecessary since all we
need is a restricted view of QueryContext.
[~jnadeau] let me know your thoughts on this.
> Provide additional information while registering storage plugin optimizer
> rules
> -------------------------------------------------------------------------------
>
> Key: DRILL-3500
> URL: https://issues.apache.org/jira/browse/DRILL-3500
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Mehant Baid
> Assignee: Mehant Baid
> Fix For: 1.2.0
>
>
> Currently all the optimizer rules internal to Drill have access to
> QueryContext. This is used by a few rules like PruneScanRule which invoke the
> interpreter to perform partition pruning. However the rules that belong to
> specific storage plugins don't have access to this information. This JIRA
> aims to do the following
> 1. Add a new interface OptimizerRulesContext that will be implemented by
> QueryContext. It will contain all the information needed by the rules. This
> context will be passed to the storage plugin method while getting the
> optimizer rules specific to that storage plugin.
> 2. Restrict existing internal rules to only accept OptimizerRulesContext
> instead of QueryContext so information in QueryContext has better
> encapsulation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
