On Wed, Jan 31, 2018 at 1:45 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
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