Fixed bugs in BufferedBlockMgr and PA.

In the case of OOM in the BufferedBlockMgr, it was returning a dangling
block pointer instead of NULL.

In PA, when spilling, there was the possibility of forgetting to finalize
the last tuple we tried to add, leading to leaked memory in the UDA.

Change-Id: Id77037aec6b351c19ec8338198a98f0b74d7addc
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4383
Reviewed-by: Nong Li <nong@cloudera.com>
Tested-by: Nong Li <nong@cloudera.com>
IMPALA-1248: Fixed CHAR(N) in VALUES clause.

Queries like;
INSERT INTO table VALUES (CAST("..." AS CHAR(N)))
Used codegen path and failed; changed to use interpreted path.

Change-Id: Id80274580df268b3f828dec19a2e0b0578061ca8
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4362
Reviewed-by: Victor Bittorf <victor.bittorf@cloudera.com>
Tested-by: jenkins
IMPALA-1072: Parquet writer is misestimating the file size.

The file size estimate was double counting plain encoded values (and one of
the counts was the uncompressed size).  Now, the file size estimate is
computed as the running uncompressed size of the dictionary, along with the
size of all finalized data pages and their headers (after compression).  (The
file size limiting heuristic already accounts for some slop needed for the not
yet finalized pages).

So that the file sizes don't change too much as a result of the change,
lower the HDFS block size / max parquet file size to 512 GB.

Thanks to Nong for the test.

I had also tested this manually with the default block size to see that
parquet files written by impala are now just under 512 GB.

Change-Id: I6b09c528a7e2372d86bbb7692eea4624125cae14
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4347
Reviewed-by: Daniel Hecht <dhecht@cloudera.com>
Tested-by: jenkins
Add metrics for number of spilled queries and total spilled bytes written.

Change-Id: Icdd06b6c2310d126278ad4c2e9f8280b4835d6f4
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4384
Reviewed-by: Nong Li <nong@cloudera.com>
Tested-by: Nong Li <nong@cloudera.com>
Analytic Functions: BE support for ROWS windows with arbitrary start bounds

Adds support in the BE AnalyticEvalNode for ROWS windows with arbitrary
start bounds. If there is a start bound specified a sliding window must
be maintained. As input rows are processed they are added to the window.
As they expire from the window, they are 'removed' from the current
intermediate state of the evaluators (stored in curr_tuple_) by calling
AggFnEvaluator::Remove(). This is an initial implementation that keeps
the tuples in the window in memory. We can improve this later by using
the BufferedTupleStream with an Iterator interface supporting multiple
readers.

This also fixes IMPALA-1253: LAST_VALUE returns incorrect results

Change-Id: Id5daf6c060ab4079bb8dacf2db8992985894a820
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4335
Reviewed-by: Matthew Jacobs <mj@cloudera.com>
Tested-by: Matthew Jacobs <mj@cloudera.com>