I think there are a couple of things going on. You may be running into some of the rounding issues covered by https://issues.apache.org/jira/browse/IMPALA-4810. In Impala 2.9 there will be a DECIMAL_V2 query option that will switch to a decimal mode that addresses some of these problem.   The expression (5.56 - 0.36) / 1200 also is treated as DOUBLE rather than DECIMAL, which is confusing and we plan to fix https://issues.apache.org/jira/browse/IMPALA-3437. If you change 1200 to 1200.0 you'll actually get a DECIMAL result. You can use the typeof() function to inspect the result types of functions:   [localhost:21000] > select typeof((5.56 - 0.36) / 1200), typeof((5.56 - 0.36) / 1200.0); +------------------------------+--------------------------------+ | typeof((5.56 - 0.36) / 1200) | typeof((5.56 - 0.36) / 1200.0) | +------------------------------+--------------------------------+ | DOUBLE | DECIMAL(11,8) | +------------------------------+--------------------------------+ Fetched 1 row(s) in 0.01s ... View more

This is a bug in the impala-udf-dev package versions 5.9.x to 5.10.x. I was alway intended to be compilable with older versions of gcc.   It will be fixed in 5.11+ once that is released. If you downgrade the package to a version 5.8.x or earlier it should also work. ... View more

It's not entirely obvious to me what changed. Since it's grouping by timestamp, you're running into https://issues.cloudera.org/browse/IMPALA-3884, which is forcing it to execute the aggregation in an interpreted mode. I suspect that the performance of that interpreted code path may have changed a bit - we tend to focus most of our tuning on the codegened code path.   On releases with IMPALA-3884 fixed it should be a *lot* faster.   "          ExecOption: Codegen Disabled: HashTableCtx::CodegenEvalRow(): type TIMESTAMP NYI" ... View more