Re: Change default of jit to off

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