Files
impala/testdata/workloads/functional-query/queries/QueryTest/spilling-no-debug-action.test
Bikramjeet Vig 77c56a805a IMPALA-7699: Fix spilling test run with hdfs erasure coding turned on
A spilling test when run on test build with hdfs erasure coding turned
on hits an out of memory error on the hdfs scan node. This happens
because the test is tuned for a regular 3 node minicluster without
hdfs erasure coding. Fix is to simply increase the memory limit on
the test to accommodate this difference yet keep it small enough to
achieve desired spilling on the hash join node.

Testing:
Ran it on an EC enabled minicluster to make sure it works

Change-Id: I207569822ba7388e78936d25e2311fa09c7a1b9a
Reviewed-on: http://gerrit.cloudera.org:8080/11740
Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
2018-10-20 03:32:07 +00:00

111 lines
3.2 KiB
Plaintext

# This file contains tests where we don't want the python test framework to supply the
# debug_action value because the test won't succeed with all possible debug_action values.
====
---- QUERY
# Tests for the case where a spilled partition has 0 probe rows and so we don't build the
# hash table in a partitioned hash join. Always runs with the minimum reservation to force
# spilling.
# INNER JOIN
set debug_action="-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0";
select straight_join count(*)
from
lineitem a, lineitem b
where
a.l_partkey = 1 and
a.l_orderkey = b.l_orderkey;
---- TYPES
BIGINT
---- RESULTS
173
---- RUNTIME_PROFILE
row_regex: .*NumHashTableBuildsSkipped: .* \([1-9][0-9]*\)
====
---- QUERY
# spilled partition with 0 probe rows, NULL AWARE LEFT ANTI JOIN
set debug_action="-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0";
select straight_join count(*)
from
lineitem a
where
a.l_partkey not in (select l_partkey from lineitem where l_partkey > 10)
and a.l_partkey < 1000;
---- TYPES
BIGINT
---- RESULTS
287
---- RUNTIME_PROFILE
row_regex: .*NumHashTableBuildsSkipped: .* \([1-9][0-9]*\)
====
---- QUERY
# spilled partition with 0 probe rows, RIGHT OUTER JOIN
set debug_action="-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0";
select straight_join count(*)
from
supplier right outer join lineitem on s_suppkey = l_suppkey
where s_acctbal > 0 and s_acctbal < 10;
---- TYPES
BIGINT
---- RESULTS
12138
---- RUNTIME_PROFILE
row_regex: .*NumHashTableBuildsSkipped: .* \([1-9][0-9]*\)
====
---- QUERY
# spilled partition with 0 probe rows, RIGHT ANTI JOIN
set debug_action="-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0";
with x as (select * from supplier limit 10)
select straight_join count(*)
from
x right anti join lineitem on s_suppkey + 100 = l_suppkey;
---- TYPES
BIGINT
---- RESULTS
5995258
---- RUNTIME_PROFILE
row_regex: .*NumHashTableBuildsSkipped: .* \([1-9][0-9]*\)
====
---- QUERY
# Aggregation query that will OOM and fail to spill because of IMPALA-3304 without
# any help from DEBUG_ACTION.
set mem_limit=100m;
select l_orderkey, group_concat(l_comment) comments
from lineitem
group by l_orderkey
order by comments desc
limit 5
---- CATCH
Memory limit exceeded
====
---- QUERY
# Top-N query with large limit that will OOM because spilling is not implemented:
# IMPALA-3471. It does not need any help from DEBUG_ACTION.
set mem_limit=100m;
select *
from lineitem
order by l_orderkey desc
limit 6000000
---- CATCH
Memory limit exceeded
====
---- QUERY
# Hash join that will fail to repartition and therefore fail from out-of-memory because
# of a large number of duplicate keys on the build side: IMPALA-4857. It does not need
# any help from DEBUG_ACTION.
set mem_limit=250m;
select straight_join *
from supplier join /* +broadcast */ lineitem on s_suppkey = l_linenumber
order by l_tax desc
limit 5
---- CATCH
row_regex:.*Cannot perform hash join at node with id .*. Repartitioning did not reduce the size of a spilled partition.*
====
---- QUERY
# Analytic query with certain kinds of large windows can't be spilled: IMPALA-5738. It
# does not need any help from DEBUG_ACTION.
set mem_limit=100m;
select avg(l_tax) over (order by l_orderkey rows between 100000000 preceding and 10000000 following)
from lineitem
---- CATCH
Memory limit exceeded
====