Re: JIT compiling with LLVM v9.0 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: JIT compiling with LLVM v9.0
Date
Msg-id 20180125070254.3akdb4crkk2kc2vm@alap3.anarazel.de
Whole thread Raw
In response to Re: JIT compiling with LLVM v9.0  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: JIT compiling with LLVM v9.0
Re: JIT compiling with LLVM v9.0
List 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


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: JIT compiling with LLVM v9.0
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem