Hi,
On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On October 8, 2018 8:03:56 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> A look in guc.c shows that jit defaults to "on" whether or not JIT is
> >> enabled at compile time.
> >> This seems, at best, rather user-unfriendly.
> >> And it's not like our conventions for other compile-option-affected
> >> GUCs, eg the SSL ones.
>
> > That was intentional, even though it perhaps should be better documented. That allows a distro to build and
distributepg without llvm enabled, but then have the JIT package with all the dependencies separately. The pg yum
packagesdo so.
>
> I'm not following. A distro wishing to do that would configure
> --with-llvm, not without, and then simply split up the build results
> so that the JIT stuff is in a separate subpackage.
Well, that'd then leave you with one more state (LLVM configured but not
installed, LLVM configured and installed, LLVM disabled and arguably
LLVM disabled but installed), but more importantly if you compile
without llvm enabled, you can still install a different extension that
would do JIT. You'd just have to set jit_provider = xyz, and it'd
work. If we made the generic JIT code depend on LLVM that'd end up
working pretty weirdly. I guess we could set jit_provider = ''
something if instead of hardcoding llvmjit if LLVM is disabled.
> If you configured --without-llvm then the resulting core code is (one
> hopes) entirely incapable of using JIT, and it'd be better if the GUC
> settings reflected that.
That's not really the case, no. It controls whether the LLVM using jit
provider is built, not whether the generic JIT handling code is
available. Given that the generic code has no dependencies, there seems
little reason to do that differently?
Greetings,
Andres Freund
