Handling performance problems with jit in postgres 12
In my opinion changing the default of jit to 'on' in v12 was a mistake, so based on that opinion turning it back off again seems pretty natural to me.  I would have objected to the change if I had been paying more attention at the time (which doesn't mean I would have prevailed, of course).  The change seems to harm at least as many people as it helps.  And the people who were looking forward to the feature could surely be counted on to go change the default.


  The defaults are sane and there is low probability they need to be changed


I think you have far too much respect for the defaults in general. They are basically set for the minimal credible machine size.  Even the settings that were well chosen in general may not be well chosen for you.


  This would also mean throwing away possible performance gains when running long queries.


Do you have example of such a query? Generally by the point the query is long-running enough that jit would make sense, it also starts touching enough data that it is no longer CPU bound and so that using jit or not is relatively unimportant (or it is missing an index, which the fixing of is far more important than jit). This is not universally true of course, and if you have an example you could then possibly use that to target the setting of jit_above_cost.  (One problem with the jit_above* things is that they are based on total cost estimates, which are generally dominated by IO cost estimates.  But choosing to use JIT or not based on estimated IO costs doesn't make sense.  But the infrastructure isn't in place to separate out those types of cost estimates.)