[jira] [Updated] (HIVE-18087) Simple select query finds nothing when non-native table has partition columns
[
https://issues.apache.org/jira/browse/HIVE-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Olson updated HIVE-18087:
Description:
First, some background info: A non-native table can be created with partition
columns defined. However, the existence of partition columns for a non-native
table is problematic. Nothing disallows the table creation, and the
documentation [1] does not mention that non-native tables cannot have partition
columns. In fact, it suggests that "PARTITIONED BY" can be specified.
With this table definition, when running a query that does not launch a MR job,
the query completes successfully and immediately, but no rows are ever
returned. I have not yet been able to identify the specific code logic path
that prevents it from working as expected, perhaps something in the query plan
related to partition pruning.
This bug is similar to HIVE-18086. We see this issue with a query like "select
\* from my_table;" and the HIVE-18086 {{NullPointerException}} with a query
like "select count(\*) from my_table;".
We encountered this bug using the {{HBaseStorageHandler}}. However, enabling
debug logging suggests that the query is being short-circuited without actually
connecting to HBase at all.
[1]
https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL
was:
A non-native table can be created with partition columns defined. However, the
existence of partition columns for a non-native table is problematic. Nothing
disallows the table creation, and the documentation [1] does not mention that
non-native tables cannot have partition columns. In fact, it suggests that
"PARTITIONED BY" can be specified.
With this table definition, when running a query that does not launch a MR job,
the query completes successfully and immediately, but no rows are ever
returned. I have not yet been able to identify the specific code logic path
that prevents it from working as expected, perhaps something in the query plan
related to partition pruning.
This bug is similar to HIVE-18086. We see this issue with a query like "select
\* from my_table;" and the HIVE-18086 NullPointerException with a query like
"select count(\*) from my_table;".
We encountered this bug using the HBaseStorageHandler. However, enabling debug
logging suggests that the query is being short-circuited without actually
connecting to HBase at all.
[1]
https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL
> Simple select query finds nothing when non-native table has partition columns
> -
>
> Key: HIVE-18087
> URL: https://issues.apache.org/jira/browse/HIVE-18087
> Project: Hive
> Issue Type: Bug
> Components: Query Processor
> Environment: CDH 5.5.5 on RHEL 6.8
>Reporter: Andrew Olson
>
> First, some background info: A non-native table can be created with partition
> columns defined. However, the existence of partition columns for a non-native
> table is problematic. Nothing disallows the table creation, and the
> documentation [1] does not mention that non-native tables cannot have
> partition columns. In fact, it suggests that "PARTITIONED BY" can be
> specified.
> With this table definition, when running a query that does not launch a MR
> job, the query completes successfully and immediately, but no rows are ever
> returned. I have not yet been able to identify the specific code logic path
> that prevents it from working as expected, perhaps something in the query
> plan related to partition pruning.
> This bug is similar to HIVE-18086. We see this issue with a query like
> "select \* from my_table;" and the HIVE-18086 {{NullPointerException}} with a
> query like "select count(\*) from my_table;".
> We encountered this bug using the {{HBaseStorageHandler}}. However, enabling
> debug logging suggests that the query is being short-circuited without
> actually connecting to HBase at all.
> [1]
> https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HIVE-18087) Simple select query finds nothing when non-native table has partition columns
[ https://issues.apache.org/jira/browse/HIVE-18087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Olson updated HIVE-18087: Description: A non-native table can be created with partition columns defined. However, the existence of partition columns for a non-native table is problematic. Nothing disallows the table creation, and the documentation [1] does not mention that non-native tables cannot have partition columns. In fact, it suggests that "PARTITIONED BY" can be specified. With this table definition, when running a query that does not launch a MR job, the query completes successfully and immediately, but no rows are ever returned. I have not yet been able to identify the specific code logic path that prevents it from working as expected, perhaps something in the query plan related to partition pruning. This bug is similar to HIVE-18086. We see this issue with a query like "select \* from my_table;" and the HIVE-18086 NullPointerException with a query like "select count(\*) from my_table;". We encountered this bug using the HBaseStorageHandler. However, enabling debug logging suggests that the query is being short-circuited without actually connecting to HBase at all. [1] https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL was: A non-native table can be created with partition columns defined. However, the existence of partition columns for a non-native table is problematic. Nothing disallows the table creation, and the documentation [1] does not mention that non-native tables cannot have partition columns. In fact, it suggests that "PARTITIONED BY" can be specified. With this table definition, when running a query that does not launch a MR job, the query completes successfully and immediately, but no rows are ever returned. I have not yet been able to identify the specific code logic path that prevents it from working as expected, perhaps something in the query plan related to partition pruning. This bug is similar to HIVE-18086. We see this issue with a query like "select * from my_table;" and the HIVE-18086 NullPointerException with a query like "select count(*) from my_table;". We encountered this bug using the HBaseStorageHandler. However, enabling debug logging suggests that the query is being short-circuited without actually connecting to HBase at all. [1] https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL > Simple select query finds nothing when non-native table has partition columns > - > > Key: HIVE-18087 > URL: https://issues.apache.org/jira/browse/HIVE-18087 > Project: Hive > Issue Type: Bug > Components: Query Processor > Environment: CDH 5.5.5 on RHEL 6.8 >Reporter: Andrew Olson > > A non-native table can be created with partition columns defined. However, > the existence of partition columns for a non-native table is problematic. > Nothing disallows the table creation, and the documentation [1] does not > mention that non-native tables cannot have partition columns. In fact, it > suggests that "PARTITIONED BY" can be specified. > With this table definition, when running a query that does not launch a MR > job, the query completes successfully and immediately, but no rows are ever > returned. I have not yet been able to identify the specific code logic path > that prevents it from working as expected, perhaps something in the query > plan related to partition pruning. > This bug is similar to HIVE-18086. We see this issue with a query like > "select \* from my_table;" and the HIVE-18086 NullPointerException with a > query like "select count(\*) from my_table;". > We encountered this bug using the HBaseStorageHandler. However, enabling > debug logging suggests that the query is being short-circuited without > actually connecting to HBase at all. > [1] > https://cwiki.apache.org/confluence/display/Hive/StorageHandlers#StorageHandlers-DDL -- This message was sent by Atlassian JIRA (v6.4.14#64029)
