You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Tim Armstrong (Jira)" <ji...@apache.org> on 2020/11/20 20:19:00 UTC

[jira] [Created] (IMPALA-10347) Explore approaches to optimizing queries that will likely be short-circuited by limits

Tim Armstrong created IMPALA-10347:
--------------------------------------

             Summary: Explore approaches to optimizing queries that will likely be short-circuited by limits
                 Key: IMPALA-10347
                 URL: https://issues.apache.org/jira/browse/IMPALA-10347
             Project: IMPALA
          Issue Type: Improvement
          Components: Distributed Exec
            Reporter: Tim Armstrong


Based on discussion with [~amansinha], there are opportunities beyond IMPALA-10314 to optimize queries where there is a limit and the query is *unlikely* to scan many files.

The problem is that we do all the work to generate scan ranges and schedule them upfront, which adds a lot of overhead if only a small number of files actually need to be processed.

A couple of ideas we had:
* Parallelize and/or otherwise optimize the scan range generation
* Speculatively execute the query on a subset of files and then cancel and retry if we hit the limit
* Incrementally generate scan ranges and assign them to executors so that scan range generation and execution can be overlapped. This is the most general solution but also has a lot of knock-on implications for other subsystems, like cardinality/memory estimation, scheduling, query execution, query coordination, etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)