Query compilation approach

[Jim Apple <jb...@cloudera.com>]

This paper will apparently be in ICDE 2018. It demonstrates an
approach to compiling queries more quickly, which it shows can be
useful for queries that run very quickly or are very complex:

https://db.in.tum.de/~leis/papers/adaptiveexecution.pdf

Re: Query compilation approach

[Tim Armstrong <ta...@cloudera.com>]

Thanks for sharing.

I think we have some of the infrastructure required to do something similar
- we have an interpreted path already and we could swap in compiled
versions of functions by updating function pointers.

Michael Ho and I have talked about doing async codegen before or even
having a codegen service that could do codegen for all instances of the
fragment (LLVM's MCJit has the infrastructure to compile the bytecode to an
unlinked binary blob, then ship it somewhere else and do the final linking).

There are definitely logistical and resource management issues with a naive
approach - if you execute the interpreted path for a bit and then do
codegen synchronously or asynchronously, then for some short-running
queries you end up with the worse of both worlds as far as CPU consumption
goes - you waste CPU cycles on the slow interpreted path and on doing the
codegen. LLVM optimisation isn't generally cancellable so if you kick that
off for a large module, it's could be stuck running long past the end of
the query.

I think the paper deals with some of those issues - estimating time taken
and doing compilation in units of small granularity, which seem like good
ideas.

On Tue, Jan 30, 2018 at 5:51 AM, Jim Apple <jb...@cloudera.com> wrote:

> This paper will apparently be in ICDE 2018. It demonstrates an
> approach to compiling queries more quickly, which it shows can be
> useful for queries that run very quickly or are very complex:
>
> https://db.in.tum.de/~leis/papers/adaptiveexecution.pdf
>