Return-Path: X-Original-To: apmail-hive-user-archive@www.apache.org Delivered-To: apmail-hive-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 322D8F72C for ; Mon, 29 Apr 2013 23:27:22 +0000 (UTC) Received: (qmail 3112 invoked by uid 500); 29 Apr 2013 23:27:19 -0000 Delivered-To: apmail-hive-user-archive@hive.apache.org Received: (qmail 3042 invoked by uid 500); 29 Apr 2013 23:27:19 -0000 Mailing-List: contact user-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hive.apache.org Delivered-To: mailing list user@hive.apache.org Received: (qmail 2955 invoked by uid 99); 29 Apr 2013 23:27:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Apr 2013 23:27:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Sean.McNamara@webtrends.com designates 216.64.169.22 as permitted sender) Received: from [216.64.169.22] (HELO pdxsmtp01.WebTrends.dmz) (216.64.169.22) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Apr 2013 23:27:13 +0000 Received: from PDXEXMAIL02.webtrends.corp (Not Verified[10.61.2.34]) by pdxsmtp01.WebTrends.dmz with MailMarshal (v6,8,4,9558) (using TLS: SSLv23) id ; Mon, 29 Apr 2013 23:26:51 +0000 Received: from PDXEXMAIL01.WebTrends.corp ([169.254.3.229]) by PDXEXMAIL02.webtrends.corp ([169.254.4.246]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 23:26:51 +0000 From: Sean McNamara To: "user@hive.apache.org" Subject: complex types and ORC Thread-Topic: complex types and ORC Thread-Index: AQHORTEGmhx/6NmQNECREIA4bGSbvg== Date: Mon, 29 Apr 2013 23:26:50 +0000 Message-ID: <012039977044474D9CFA6A36A4D1FF66F5C51B@PDXEXMAIL01.webtrends.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.2.4] Content-Type: multipart/alternative; boundary="_000_012039977044474D9CFA6A36A4D1FF66F5C51BPDXEXMAIL01webtre_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_012039977044474D9CFA6A36A4D1FF66F5C51BPDXEXMAIL01webtre_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If I create a table that has a map field, will ORC files co= lumnarize by the keys in the map? Or will all the pairs in the map be grou= ped together? My goal is to columnarize the storage of a variable number of fields (where= the names and number of fields are unknown at schema creation). It does n= ot appear to be possible with RCFILE, and I'm curious if ORC just adds bett= er type support, or if they also columnarize the fields within complex type= s. Thanks, Sean --_000_012039977044474D9CFA6A36A4D1FF66F5C51BPDXEXMAIL01webtre_ Content-Type: text/html; charset="us-ascii" Content-ID: <567ED0D820F4EF408962F0F19A242618@WebTrends.com> Content-Transfer-Encoding: quoted-printable

If I create a table that has a map<string, string> field, will O= RC files columnarize by the keys in the map? Or will all the pairs in= the map be grouped together?

My goal is to columnarize the storage of a variable number of fields (= where the names and number of fields are unknown at schema creation). = ;It does not appear to be possible with RCFILE, and I'm curious if ORC just= adds better type support, or if they also columnarize the fields within complex types.

Thanks,

Sean

--_000_012039977044474D9CFA6A36A4D1FF66F5C51BPDXEXMAIL01webtre_--