Make wait() method wait for query execution

[xyu]

With Impala the \ThriftSQL\ImpalaQuery object is ready as soon as the query is parsed / accepted to match up with wait() method with Hive fetch up to the first 2 rows during the wait() method so that the query gets executed.

[bperson]

s/query/results/ ?

[xyu]

This is part of the problem, sometimes the thrift query handle gets the query state marked as FINISHED before the query is ready to return results. Perhaps it gets marked as finished when fragments finish executing but before the gateway aggregates the results?

This can be seen if we run something like SELECT sleep(5000) which will return almost immediately even with wait() called on it. Then the initial fetch() call will take ~5s before it returns results.

I'm not sure if this change is being too clever with trying to wait for the initial fetch as well which might be just an edge case with the UDF.

[bperson]

I'm not sure if this change is being too clever with trying to wait for the initial fetch as well which might be just an edge case with the UDF.

Yeah my bad, I should have read the whole thing and that there are actually 2 distinct waits ( which your comments explained quite well in fact, I should stop commenting as I go when reviewing and do a first full pass :D ).

I'd keep it as-is though: should we maybe try it with the cupcakes query that triggered this investigation?

[bperson]

I'm not sure how to test it tbh, but wouldn't this "consume" those 2 results as well as waiting? Such that when you fetch afterwards, you won't get those 2 initial results used for waiting?

[xyu]

So that's why _fetchResponse() stores the result in $this->_lastResponse and when fetch() gets called it consumes that response first.

[xyu]

@bperson so the only required change to make calling wait() in the locked ThriftSQL class work is to add the two ready tests E.g.:

    if ( $this->_ready ) {
      return $this;
    }

To make sure it's safe to call wait() multiple times on the same query.

The hacky fetch() within wait() thing fixes some edge cases but maybe they are not important enough for us to really care. Most "normal" queries that spend most of their time reading HDFS and processing remote fragments do indeed spend most of their time during the existing wait() call. What do you think we should do? Get rid of the hacky thing to make the code a bit less surprising?

[bperson]

Talked with Xiao in Slack, the plan is to cut the extra complexity to add the "wait to fetch the first 2 rows" for now since we aren't sure it's actually needed for real queries that aren't just edge-cases like 'SELECT sleep(10000);"