Re: JIT compiling with LLVM v9.0

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JIT compiling with LLVM v9.0
Date: 2018-01-25 07:02:54
Message-ID: 20180125070254.3akdb4crkk2kc2vm@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On 2018-01-24 22:51:36 -0800, Jeff Davis wrote:
> A couple high-level questions:
>
> 1. I notice a lot of use of the LLVM builder, for example, in
> slot_compile_deform(). Why can't you do the same thing you did with
> function code, where you create the ".bc" at build time from plain C
> code, and then load it at runtime?

Not entirely sure what you mean. You mean why I don't inline
slot_getsomeattrs() etc and instead generate code manually? The reason
is that the generated code is a *lot* smarter due to knowing the
specific tupledesc.

> 2. I'm glad you considered extensions. How far can we go with this in
> the future?

> Can we have bitcode-only extensions that don't need a .so
> file?

Hm. I don't see a big problem introducing this. There'd be some
complexity in how to manage the lifetime of JITed functions generated
that way, but that should be solvable.

> Can we store the bitcode in pg_proc, simplifying deployment and
> allowing extensions to travel over replication?

Yes, we could. You'd need to be a bit careful that all the machines have
similar-ish cpu generations or compile with defensive settings, but that
seems okay.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-01-25 07:11:22 Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Previous Message Jeff Davis 2018-01-25 06:51:36 Re: JIT compiling with LLVM v9.0