On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund <and...@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
