Add support for elasticsearch async requests

[sebastian-lundqvist]

When you don't have narrow filters you can often get pretty big & heavy requests that take a long time to fully load in the PLB, this could maybe be used to alleviate that.

[kuseman]

A classic scroll is already performed today and from what I understand the async one is just a different kind of way of retrieving results partially.

But either way that is not going to speed up things if I understand what you are after. The problem is how the query pipeline works in PLB (and other query engines too).

Take this query for example (which is really heavy):

select *
from _doc
where _someField = 'someValue'    (assuming that _someField is indexed in elastic ang queryable)

The query plan for that query will be a simple scan operator with a predicate pushed down to Elastic catalog

  scan: _doc (query: "{ "term": { "_someField": "someValue" } }" )

.. and that operator must wait for the result to come back before returning it back to PLB, so no matther if you use sync/async query against ES it will take as long as it takes for Elasic to return it, and that is per batch of the scroll/async result.

To show even more why it must be this way let's extend the query above with a join:

select *
from _doc d
inner join _doc d1
  on d1._someOtherField = d._someOtherFieldTwo
where d._someField = 'someValue'

.. we are ending up with an plan like this:

  join:                   (some join algo. nested loop, hash join, etc.)
    scan: _doc (d)
    scan: _doc (d1)

And the way a join works is that we need all rows from both inputs before we can start to match rows, so even if we used an async call we would have to wait until the result comes back so that basically means that we would wrap the async call with a sync that waits until the async call returns :)