Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Thu, 23 Feb 2017 20:27:44 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.13043314.1487180108000.47355.1487881664247@Atlassian.JIRA>
In-Reply-To: <JIRA.13043314.1487180108000@Atlassian.JIRA>
References: <JIRA.13043314.1487180108000@Atlassian.JIRA> <JIRA.13043314.1487180108945@jira-lw-us.apache.org>
Subject: [jira] [Commented] (DRILL-5266) Parquet Reader produces "low
 density" record batches - bits vs. bytes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 23 Feb 2017 20:27:49 -0000


    [ https://issues.apache.org/jira/browse/DRILL-5266?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1588=
1190#comment-15881190 ]=20

ASF GitHub Bot commented on DRILL-5266:
---------------------------------------

Github user paul-rogers commented on a diff in the pull request:

    https://github.com/apache/drill/pull/749#discussion_r102809881
 =20
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/parq=
uet/columnreaders/ParquetRecordReader.java ---
    @@ -73,6 +72,7 @@
       private static final long DEFAULT_BATCH_LENGTH =3D 256 * 1024 * NUMB=
ER_OF_VECTORS; // 256kb
       private static final long DEFAULT_BATCH_LENGTH_IN_BITS =3D DEFAULT_B=
ATCH_LENGTH * 8; // 256kb
       private static final char DEFAULT_RECORDS_TO_READ_IF_NOT_FIXED_WIDTH=
 =3D 32*1024;
    --- End diff --
   =20
    Fixed.


> Parquet Reader produces "low density" record batches - bits vs. bytes
> ---------------------------------------------------------------------
>
>                 Key: DRILL-5266
>                 URL: https://issues.apache.org/jira/browse/DRILL-5266
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Storage - Parquet
>    Affects Versions: 1.10
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>              Labels: ready-to-commit
>
> Testing with the managed sort revealed that, for at least one file, Parqu=
et produces "low-density" batches: batches in which only 5% of each value v=
ector contains actual data, with the rest being unused space. When fed into=
 the sort, we end up buffering 95% of wasted space, using only 5% of availa=
ble memory to hold actual query data. The result is poor performance of the=
 sort as it must spill far more frequently than expected.
> The managed sort analyzes incoming batches to prepare good memory use est=
imates. The following the the output from the Parquet file in question:
> {code}
> Actual batch schema & sizes {
>   T1=C2=A6=C2=A6cs_sold_date_sk(std col. size: 4, actual col. size: 4, to=
tal size: 196608, vector size: 131072, data size: 4516, row capacity: 32768=
, density: 4)
>   T1=C2=A6=C2=A6cs_sold_time_sk(std col. size: 4, actual col. size: 4, to=
tal size: 196608, vector size: 131072, data size: 4516, row capacity: 32768=
, density: 4)
>   T1=C2=A6=C2=A6cs_ship_date_sk(std col. size: 4, actual col. size: 4, to=
tal size: 196608, vector size: 131072, data size: 4516, row capacity: 32768=
, density: 4)
> ...
>   c_email_address(std col. size: 54, actual col. size: 27, total size: 53=
248, vector size: 49152, data size: 30327, row capacity: 4095, density: 62)
>   Records: 1129, Total size: 32006144, Row width:28350, Density:5}
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)