Re: Euler Taveira > > +1 on disabling jit by default. At the FOSDEM Postgres developer meeting > > consensus was hugely in favor of changing the default. So attached is a > > trivial patch that does this.
I'm also in favor of disabling it by default. It's mostly hurting people (or use cases) in OLTP workloads where it's just surprising that JIT kicks in, while in OLAP workloads, people would usually know they have a use for JIT and could enable it. There are several layers of "default" here: 1) the default when compiling without extra options 2) the default when compiling with LLVM 3) the default in the deb/rpm/... packages with just "postgresql" installed 4) the default in the deb/rpm/... packages with the JIT package installed 5) the default that cloud providers set when using these/their own packages The setting for 1) is off, so you might argue that for all other cases, someone has made a conscious choice to enable it for the other options, but for 3/5) and likely also for 4), that decision wasn't made by the user actually using the database, so they don't have any influence on it. In these cases, disabling it would remove the "surprise" moment. That leaves 2), but I would argue that all the cases should behave the same. If different installs have different defaults, that's hard to communicate. > You can argue that the majority of the workloads are > not composed by analytic queries. Fine. That's not an excuse to perform poorly > with a small percentage of these analytic queries. It's neither an excuse to perform poorly on the OLTP queries that got JITed when they should not have. > Since there are some reports exposing these issues and articles discussing it, > I would suggest improving the documentation stating that there are issues in > this area and that they will be resolved in the future. (The documentation > already stated the common issue -- short queries -- in the first paragraph > [2]. > Maybe we need to be more incisive.) Documentation won't help here. This is always biting users by surprise. Telling them that their non-analytic workload performs poorly because they didn't read the JIT chapter when it shouldn't be relevant to them is quite weird. > Instead, of using the argument that JIT hurts short queries, I would like to > see other alternative solutions for this JIT issue. The v15 added some columns > to pg_stat_statements that helps us understand if JIT is hurting your queries. > I don't have numbers but instead of turning JIT off we should adopt a less > invasive solution like increasing the thresholds that triggers it -- > jit_*_above_cost (probably using some pg_stat_statements reports). It is not a > definitive fix, JIT needs improvement and an idea like making JIT more > granular > [3] could restore confidence in it. I've been pondering this as well, but I think we aren't there yet. It will still make the compiler jump in in situations where it shouldn't (maybe the cost estimates are just wildly off, but often the planner still finds a good OLTP plan). We want predictability here. > Although I don't have plans to hack on JIT code but > reports may encourage a few developers to propose changes in this area. We'd need people to actually work out the cost parameters. :) Christoph
