Re: JIT compiling with LLVM v9.0

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JIT compiling with LLVM v9.0
Date: 2018-02-01 14:51:17
Message-ID: CAHyXU0y_poFEPnOeGxGKVeaROwja3SS4k=hbP192Ccmjf6Wusw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 31, 2018 at 1:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> 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.
>
> We could do that, but I'd be more inclined just to let JIT be
> magically enabled. In general, if a user could do 'yum install ip4r'
> (for example) and have that Just Work without any further database
> configuration, I think a lot of people would consider that to be a
> huge improvement. Unfortunately we can't really do that for various
> reasons, the biggest of which is that there's no way for installing an
> OS package to modify the internal state of a database that may not
> even be running at the time. But as a general principle, I think
> having to configure both the OS and the DB is an anti-feature, and
> that if installing an extra package is sufficient to get the
> new-and-improved behavior, users will like it. Bonus points if it
> doesn't require a server restart.

You bet. It'd be helpful to have some obvious, well advertised ways
to determine when it's enabled and when it isn't, and to have a
straightforward process to determine what to fix when it's not enabled
and the user thinks it ought to be though.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-02-01 14:51:18 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Simon Riggs 2018-02-01 14:47:35 Re: [HACKERS] make async slave to wait for lsn to be replayed