I was able to reproduce it myself on several versions of CDH. I filed a bug report to track it: https://issues.apache.org/jira/browse/IMPALA-6389 . Thank you very much for letting us know about this. ... View more

Hi @Plop564,   Thanks for the quality question.   1) It's also used by a lot of Impala builtin functions (we implement many with the exact same interface as UDFs). 2) It could be a bug in a UDF/UDAF. It's also possible that there's a bug in Impala where Impala isn't cleaning up the local allocations during some operation. E.g. in older versions if you ordered by a UDF that allocated memory, then a lot of that memory was only cleaned up at the end of the sort.   It's possible that you could be allocating a lot of memory with FunctionContextImpl::Allocate() and Free() as well. The memory allocated in that way counts against the same limits as AllocateLocal() for the most part. ... View more

I believe the original reason that it took seconds was for compatibility with Mysql's similarly-named function.   You can convert a millisecond unix timestamp into an Impala timestamp more efficiently using integer division/mod and the "interval" operator as follows:   [localhost:21000] > select cast(1513895588243 div 1000 as timestamp) + interval (1513895588243 % 1000) milliseconds; +------------------------------------------------------------------------------------------+ | cast(1513895588243 div 1000 as timestamp) + interval (1513895588243 % 1000) milliseconds | +------------------------------------------------------------------------------------------+ | 2017-12-21 22:33:08.243000000 | +------------------------------------------------------------------------------------------+ Fetched 1 row(s) in 0.01s ... View more