Uploaded image for project: 'IMPALA'
  1. IMPALA
  2. IMPALA-4016

Avoid materializing slots only referenced by Kudu conjuncts

    Details

      Description

      Right now, when SlotRefs are serialized to Thrift, Impala makes sure the slots are materialized. For Kudu we only need to mark them as materialized to build the kudu predicates, meaning the slots might not be referenced in the projection at all. In this case we should avoid materializing the slots (and thus allocating memory).

      I believe that when we move to the scan token API we can avoid marking the SlotRefs as materialized.

        Issue Links

          Activity

          Hide
          mjacobs Matthew Jacobs added a comment -

          commit 157c80056c62c89193a04d147d8c94fcb58610c4
          Author: Matthew Jacobs <mj@cloudera.com>
          Date: Fri Aug 19 08:49:25 2016 -0700

          IMPALA-3481: Use Kudu ScanToken API for scan ranges

          Switches the planner and KuduScanNode to use Kudu's new
          ScanToken API instead of explicitly constructing scan ranges
          for all tablets of a table, regardless of whether they were
          needed. The ScanToken API allows Impala to specify the
          projected columns and predicates during planning, and Kudu
          returns a set of 'scan tokens' that represent a scanner for
          each tablet that needs to be scanned. The scan tokens can
          be serialized and distributed to the scan nodes, which can
          then deserialize them into Kudu scanner objects. Upon
          deserialization, the scan token has all scan parameters
          already, including the 'pushed down' predicates. Impala no
          longer needs to send the Kudu predicates to the BE and
          convert them at the scan node.

          This change also fixes:
          1) IMPALA-4016: Avoid materializing slots only referenced
          by Kudu conjuncts
          2) IMPALA-3874: Predicates are not always pushed to Kudu

          TODO: Consider additional planning improvements.

          Testing: Updated the existing tests, verified everything
          works as expected. Some BE tests no longer make sense and
          they were removed.

          TODO: When KUDU-1065 is resolved, add tests that demonstrate pruning.

          Change-Id: I160e5849d372755748ff5ba3c90a4651c804b220
          Reviewed-on: http://gerrit.cloudera.org:8080/4120
          Reviewed-by: Matthew Jacobs <mj@cloudera.com>
          Tested-by: Internal Jenkins

          Show
          mjacobs Matthew Jacobs added a comment - commit 157c80056c62c89193a04d147d8c94fcb58610c4 Author: Matthew Jacobs <mj@cloudera.com> Date: Fri Aug 19 08:49:25 2016 -0700 IMPALA-3481 : Use Kudu ScanToken API for scan ranges Switches the planner and KuduScanNode to use Kudu's new ScanToken API instead of explicitly constructing scan ranges for all tablets of a table, regardless of whether they were needed. The ScanToken API allows Impala to specify the projected columns and predicates during planning, and Kudu returns a set of 'scan tokens' that represent a scanner for each tablet that needs to be scanned. The scan tokens can be serialized and distributed to the scan nodes, which can then deserialize them into Kudu scanner objects. Upon deserialization, the scan token has all scan parameters already, including the 'pushed down' predicates. Impala no longer needs to send the Kudu predicates to the BE and convert them at the scan node. This change also fixes: 1) IMPALA-4016 : Avoid materializing slots only referenced by Kudu conjuncts 2) IMPALA-3874 : Predicates are not always pushed to Kudu TODO: Consider additional planning improvements. Testing: Updated the existing tests, verified everything works as expected. Some BE tests no longer make sense and they were removed. TODO: When KUDU-1065 is resolved, add tests that demonstrate pruning. Change-Id: I160e5849d372755748ff5ba3c90a4651c804b220 Reviewed-on: http://gerrit.cloudera.org:8080/4120 Reviewed-by: Matthew Jacobs <mj@cloudera.com> Tested-by: Internal Jenkins

            People

            • Assignee:
              mjacobs Matthew Jacobs
              Reporter:
              mjacobs Matthew Jacobs
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development