It seems that the query involves dynamic partitioning, but the dynamic partition column is not included in either the select statement or the Common Table Expression (CTE). Please add the dynamic partition column 'date' to the select statement and validate it in Beeline. ... View more

Hi,   After you run the query you need to look at the query profile to analyse the complete memory. look for “Per node peak memory usage” in the profile to understand how much memory each host or impala daemon used to run this query.   For above snippet from your side it looks like this query has the 3gb max limit to run the query, this can be set at session level or in impala admission control pool. If you provide the complete query profile i think we can get more details. Regards, Chethan YM   ... View more

Hi, I have some points to that questions: The order of the parameter does not matter If you do not persist the settings in the configuration, you have to apply them at the start of each session Those parameters are not the holy grail. Vectorized execution can lead to errors and wrong results under specific circumstances and should only be used if it is required and known to work with the used UDFs. Using CBO/fetching stats can improve your performance. Under the wrong circumstances - it can lead to a long gathering period for stats at the end of a query that maybe is worse than the performance gain. Auto convert join should only be used if you know the sizes of the tables. Setting this property to true will trigger mapjoin only if one table fits in your memory otherwise there will be no use in setting this to true and you will not find any optimization in your runtime.   I really can recommend you that article by a fellow Clouderan: https://community.cloudera.com/t5/Community-Articles/Hive-on-Tez-Performance-Tuning-Determining-Reducer-Counts/ta-p/245680   If you have concrete questions to optimize a specific query do not hesitate to ask.  ... View more