Re: JIT compiling with LLVM v9.0
От | Andres Freund |
---|---|
Тема | Re: JIT compiling with LLVM v9.0 |
Дата | |
Msg-id | 20180125070254.3akdb4crkk2kc2vm@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: JIT compiling with LLVM v9.0 (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: JIT compiling with LLVM v9.0
Re: JIT compiling with LLVM v9.0 |
Список | 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 по дате отправления: