On Wed, Jan 31, 2018 at 2:49 PM, Andres Freund <and...@anarazel.de> wrote: >> 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. > > I'm not seing a contradiction between what you describe as desired, and > what I describe? If it defaulted to try, that'd just do what you want, > no? I do think it's important to configure the system so it'll error if > JITing is not available.
Hmm, I guess that's true. I'm not sure that we really need a way to error out if JIT is not available, but maybe we do. >> Bonus points if it doesn't require a server restart. > > I think server restart might be doable (although it'll increase memory > usage because the shlib needs to be loaded in each backend rather than > postmaster), but once a session is running I'm fairly sure we do not > want to retry. Re-checking whether a shlib is available on the > filesystem every query does not sound like a good idea... Agreed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
