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
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 |