We had an issue filed for this a while back: https://issues.cloudera.org/browse/IMPALA-3293 . It seems fairly reasonable but I think will depend on how much demand there is for it (or if someone contributes a patch for it). ... View more

This would typically happen if the catalog daemon was restarted. ... View more

If you're using impala-shell, you can use the "summary;" command. Otherwise it's accessible through the Impala debug web pages (typically http://the-impala-server:25000) ... View more

Please do open a JIRA - it's always good to have some context on the problem from users.   It looks like the scanners in that profile are just idle (based on the user and system time)  - so my guess is that the slowdown is something further up on the plan. ... View more

One thing to keep in mind when interpreting the profiles is that a series of joins will typically be pipelined to avoid materialising results. This means that the whole pipeline runs at the speed of the slowest part of the pipeline. So the limiting factor could be the client (if you're returning a lot of results), the scan at the bottom of the plan, or any of the joins in the pipeline.   TotalNetworkSendTime may be somewhat misleading since if the sender is running faster than the receiver, a backpressure mechanism kicks in that blocks the sender until the receiver has caught up.   What's I'd recommend initially is comparing query summaries of the fast and slow queries to see where the difference in time is.   If you're running in impala-shell you can get the summary of the last query by typing "summary;" ... View more

Good to hear! Please feel free to mark it as solved to make it easier for others to find. ... View more

Some examples of the calculations and numbers would be helpful.   We use a C++ double as the underlying type, so have the same precision. There are a lot of subtleties with floating point numbers where calculations that are mathematically equivalent with real numbers can give different results with floating point numbers. E.g floating point arithmetic is not associative, so it's not guaranteed that a + b + c == a + c + b.   On x86 there's also some additional weirdness where intermediate results of calculations are represented with 80-bits if they're kept in floating-point registers but reduced in precision to 64-bits if they're written to memory: https://en.wikipedia.org/wiki/Extended_precision. At the C++ or SQL levels you have very little control over which precision is used.   Fixed-precision decimal will give you more predictable results if your application isn't tolerant to rounding errors. ... View more