Re: JIT compiling with LLVM v11

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Catalin Iacob <iacobcatalin(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>
Subject: Re: JIT compiling with LLVM v11
Date: 2018-03-15 16:42:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-03-15 12:33:08 -0400, Tom Lane wrote:
>> The "software collections" stuff was still in its infancy when I left
>> Red Hat, so things might've changed, but I'm pretty sure at the time
>> it was verboten for any mainstream package to depend on an SCL one.

> But we won't get PG 11 into RHEL7.x either way, no?

Well, they've been known to back-port newer releases of PG into older
RHEL; I wouldn't necessarily assume it'd happen for 11, but maybe 12
or beyond could be made available for RHEL7 at some point.

>> But they very probably wouldn't want postgresql depending on a
>> compiler package even if the dependency was mainstream, so I rather
>> doubt that you'll ever see an --enable-jit PG build out of there,
>> making this most likely moot as far as the official RH package goes.
>> I don't know what Devrim's opinion might be about PGDG.

> It'd be a build not runtime dependency, doesn't that change things?

How could it not be a runtime dependency? You're not proposing that
we'd embed all of LLVM into a Postgres package are you? If you are, be
assured that Red Hat will *never* ship that. Static linking/embedding of
one package in another is forbidden for obvious maintainability reasons.
I would think that other distros have similar policies.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2018-03-15 17:04:07 Re: SQL/JSON: functions
Previous Message Alvaro Herrera 2018-03-15 16:39:52 Re: chained transactions