[
https://issues.apache.org/jira/browse/DRILL-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057149#comment-15057149
]
Venki Korukanti edited comment on DRILL-4194 at 12/15/15 1:40 AM:
------------------------------------------------------------------
Had a discussion with [~jni] & [~amansinha100], regarding getting
parallelization info in logical to physical conversion (in {{ScanPrule}}):
Getting parallelization info in {{ScanPrule}} is costly because partition
pruning is not done by then. If we move the Hive partition pruning to logical
space (just like the filesystem partition pruning), it should be ok to get
parallelization info in {{ScanPrule}}. Logged DRILL-4198 to add an interface
method to {{StoragePlugin}} to expose the plugin specific logical rules to
planner and move Hive partition pruning rules to logical space.
was (Author: vkorukanti):
Had a discussion with [~jni] & [~amansinha100], regarding getting
parallelization info in logical to physical conversion (in {{ScanPrule}}:
Getting parallelization info in {{ScanPrule}} is costly because partition
pruning is not done by then. If we move the Hive partition pruning to logical
space (just like the filesystem partition pruning), we don't need to add any
new methods to {{GroupScan}} to indicate whether the {{GroupScan}} is singleton
or not. Logged DRILL-4198 to add an interface method to {{StoragePlugin}} to
expose the plugin specific logical rules to planner and move Hive partition
pruning rules to logical space.
> Improve the performance of metadata fetch operation in HiveScan
> ---------------------------------------------------------------
>
> Key: DRILL-4194
> URL: https://issues.apache.org/jira/browse/DRILL-4194
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
> Affects Versions: 1.4.0
> Reporter: Venki Korukanti
> Assignee: Venki Korukanti
> Fix For: 1.5.0
>
>
> Current HiveScan fetches the InputSplits for all partitions when {{HiveScan}}
> is created. This causes long delays when the table contains large number of
> partitions. If we end up pruning majority of partitions, this delay is
> unnecessary.
> We need this InputSplits info from the beginning of planning because
> * it is used in calculating the cost of the {{HiveScan}}. Currently when
> calculating the cost first we look at the rowCount (from Hive MetaStore), if
> it is available we use it in cost calculation. Otherwise we estimate the
> rowCount from InputSplits.
> * We also need the InputSplits for determining whether {{HiveScan}} is a
> singleton or distributed for adding appropriate traits in {{ScanPrule}}
> Fix is to delay the loading of the InputSplits until we need. There are two
> cases where we need it. If we end up fetching the InputSplits, store them
> until the query completes.
> * If the stats are not available, then we need InputSplits
> * If the partition is not pruned we need it for parallelization purposes.
> Regarding getting the parallelization info in {{ScanPrule}}: Had a discussion
> with [~amansinha100]. All we need at this point is whether the data is
> distributed or singleton at this point. Added a method {{isSingleton()}} to
> GroupScan. Returning {{false}} seems to work fine for HiveScan, but I am not
> sure of the implications here. We also have {{ExcessiveExchangeIdentifier}}
> which removes unnecessary exchanges by looking at the parallelization info. I
> think it is ok to return the parallelization info here as the pruning must
> have already completed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
