impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Skye Wanderman-Milne (Code Review)" <>
Subject [Impala-CR](cdh5-trunk) IMPALA-2853: introduce PARQUET_RESOLVE_BY_NAME query option
Date Mon, 21 Mar 2016 18:28:46 GMT
Skye Wanderman-Milne has posted comments on this change.

Change subject: IMPALA-2853: introduce PARQUET_RESOLVE_BY_NAME query option

Patch Set 3:

File be/src/exec/

Line 2025:   if (col_type == NULL) DCHECK_EQ(next_idx, 0);
> with the new way the code is structured, this might be more intuitive writt
File be/src/exec/hdfs-parquet-scanner.h:

Line 599: a value >= # 
> how about just simplify:
File common/thrift/ImpalaInternalService.thrift:

Line 169:   42: optional bool parquet_resolve_by_name = false
> while i see your point about resolve-by-id needing a fallback, I think this
Given that the only meaningful resolution orderings are:
* id, name
* id, ordinal
* name
* ordinal

And that field IDs don't actually exist yet, I think we should keep this option (or change
it to resolve_by_ordinal if that's somehow better), and later add a parquet_resolve_by_field_id
option as well. If we get the field ids in by C6, we can rename this option to parquet_resolve_legacy_files_by_name
or something.

At the very least, even if field IDs aren't implemented by C6, we can still rename this option
if we come up with something better.
File testdata/workloads/functional-query/queries/QueryTest/parquet-resolution-by-name.test:

Line 55: '/test-warehouse/nested_resolution_by_name_test_parquet'

Line 170: ====
> any way to test the map key/value logic?
One way would be to generate custom files with switched and renamed fields. Or, with some
light refactoring, I think it should  be possible to unit test this case (and others). I think
the only non-trival change would be changing the table descriptor to contain a single root
record type that has all the column types as children, instead of special-casing the table-level

I'll send an email to the dev list about the column type change, since I think this is a good
idea either way. Let me know what you think about unit testing vs generating files for end-to-end
tests. I can do either, but I think unit testing will be better. If it turns out to be a bigger
change than anticipated I'll just generate the files.
File tests/common/

Line 224: EXECUTE
> maybe call it 'SHELL' since execute has many meanings?
Good idea, done
File tests/query_test/

Line 240: 
> skip if s3 insert

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Id0c715ea23792b2a6872610839a40532aabbb5a6
Gerrit-PatchSet: 3
Gerrit-Project: Impala
Gerrit-Branch: cdh5-trunk
Gerrit-Owner: Skye Wanderman-Milne <>
Gerrit-Reviewer: Dan Hecht <>
Gerrit-Reviewer: Michael Ho <>
Gerrit-Reviewer: Silvius Rus <>
Gerrit-Reviewer: Skye Wanderman-Milne <>
Gerrit-HasComments: Yes

View raw message