|From:||Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Defaulting to jit=on/off for v11|
|Views:||Raw Message | Whole Thread | Download mbox|
I kind of thought I'd sent out this mail Friday morning, but apparently
I forgot to hit send, before accidentally releasing my laptop's battery
while running :/
We'd agreed a while ago, when JIT compilation landed, to decide close to
the release whether JIT compilation should be enabled or disabled by
default. It seems the time for that has come.
I think there's several angles to this:
* Enabling by default will give far greater exposure, making it much
more likely that we'll fix bugs earlier, meaning fewer people will be
caught later when they already thought everything should be perfectly
stable. We'll want to enable the feature by default at some point, so
that'd be good way to get there fast.
* There's a number of cases where JIT compilation triggers over-eagerly:
In particular when costs are widely off (e.g. in the regression tests
due to an un-analyzed table), or when the majority of the cost is
incurred from things like enable_*=off. That can cause slowdowns. If
we had caching of JITed code, that'd not be that bad, but we don't.
* There's a substantial risk that the JIT feature has bugs - it was
largely written by a single person (i.e. me), nontrivial and there
definitely have been features that have been more widely reviewed.
* Disabling it by default will prevent people from "automatically"
I can see basically three sensible routes to go for v11 (before we
1) Leave it enabled, as currently.
2) Disable it by default in v11, leave it enabled in master.
3) Increase the costs substantially, so it triggers in far fewer
cases. Those would be too high for cases that want to benefit fully,
but would reduce the risk - although it also probably makes it
harder to easily hit problematic cases.
I personally can see reasons to go with either of these, and don't have
a real preference myself.
|Next Message||Tom Lane||2018-09-14 22:32:03||Re: Defaulting to jit=on/off for v11|
|Previous Message||Tom Lane||2018-09-14 21:32:22||Re: pg_dump test instability|