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 20180131183436.j4xiwmuxwyixhc6b@alap3.anarazel.de
Whole thread Raw
In response to Re: JIT compiling with LLVM v9.0  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: JIT compiling with LLVM v9.0  (Robert Haas <robertmhaas@gmail.com>)
Re: JIT compiling with LLVM v9.0  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2018-01-31 11:53:25 -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> > On 1/30/18 21:55, Andres Freund wrote:
> >> I'm open to changing my mind on it, but it seems a bit weird that a
> >> feature that relies on a shlib being installed magically turns itself on
> >> if avaible. And leaving that angle aside, ISTM, that it's a complex
> >> enough feature that it should be opt-in the first release... Think we
> >> roughly did that right for e.g. parallellism.
> >
> > That sounds reasonable, for both of those reasons.
> 
> The first one is a problem that's not going to go away.  If the
> problem of JIT being enabled "magically" is something we're concerned
> about, we need to figure out a good solution, not just disable the
> feature by default.

That's a fair argument, and I don't really have a good answer to it. We
could have a jit = off/try/on, and use that to signal things? I.e. it
can be set to try (possibly default in version + 1), and things will
work if it's not installed, but if set to on it'll refuse to work if not
enabled. Similar to how huge pages work now.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Next
From: Andres Freund
Date:
Subject: Re: JIT compiling with LLVM v9.0