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

From Robert Haas
Subject Re: JIT compiling with LLVM v9.0
Date
Msg-id CA+TgmoaE_EEumfeWdJxUow4WK1mgYS+cvkik2vx02hqOPEkwmg@mail.gmail.com
Whole thread Raw
In response to Re: JIT compiling with LLVM v9.0  (Andres Freund <andres@anarazel.de>)
Responses Re: JIT compiling with LLVM v9.0
Re: JIT compiling with LLVM v9.0
Re: JIT compiling with LLVM v9.0
List pgsql-hackers
On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund <andres@anarazel.de> wrote:
> It's an optional dependency, and it doesn't increase build time that
> much... If we were to move the llvm interfacing code to a .so, there'd
> not even be a packaging issue, you can just package that .so separately
> and get errors if somebody tries to enable LLVM without that .so being
> installed.

I suspect that would be really valuable.  If 'yum install
postgresql-server' (or your favorite equivalent) sucks down all of
LLVM, some people are going to complain, either because they are
trying to build little tiny machine images or because they are subject
to policies which preclude the presence of a compiler on a production
server.  If you can do 'yum install postgresql-server' without
additional dependencies and 'yum install postgresql-server-jit' to
make it go faster, that issue is solved.

Unfortunately, that has the pretty significant downside that a lot of
people who actually want the postgresql-server-jit package will not
realize that they need to install it, which sucks.  But I think it
might still be the better way to go.  Anyway, it's for individual
packagers to cope with that problem; as far as the patch goes, +1 for
structuring things in a way which gives packagers the option to divide
it up that way.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound
Next
From: Robert Haas
Date:
Subject: Re: JIT compiling with LLVM v9.0