On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund <andres@anarazel.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
