Feedback-ID: i0c21471d:Fastmail
MIME-Version: 1.0
Date: Mon, 02 Feb 2026 21:42:25 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Jelte Fennema" <postgres@jeltef.nl>,
 "Pierre Ducroquet" <p.psql@pinaraf.info>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
 "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>,
 "Andreas Karlsson" <andreas@proxel.se>,
 "Anthonin Bonnefoy" <anthonin.bonnefoy@datadoghq.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 "Michael Banck" <mbanck@gmx.net>, "Christoph Berg" <myon@debian.org>
Message-Id: <56a7e683-434f-4d2d-a7ed-9ddefcf426f4@app.fastmail.com>
In-Reply-To: <DG1VZJEX1AQH.2EH4OKGRUDB71@jeltef.nl>
References: <DG1VZJEX1AQH.2EH4OKGRUDB71@jeltef.nl>
Subject: Re: Change default of jit to off
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/56a7e683-434f-4d2d-a7ed-9ddefcf426f4%40app.fastmail.com>
Precedence: bulk

On Fri, Jan 30, 2026, at 8:28 AM, Jelte Fennema-Nio wrote:
>
> +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.
>

As someone that analyzed dozens of cases that JIT performs poorly, I would say
+1. However, I don't think it is a good idea. JIT was introduced in v11
(defaults to off) and the default was changed to on for v12. As Jeff said [1] I
also think it was premature. It's been 7 years that JIT is enabled by default
and changing this parameter could surprise users who use JIT to mainly improve
runtime from OLAP queries. 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. Will you propose enabling it
again after fixing the majority of these performance reports? That will be
another source of confusion.

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.)

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.

Maybe I'm being too optimistic but this is a similar argument that kept
optimizer hints out of core: hints can reduce the pace of planner improvements
since fewer bad query plans are reported due to use of hints to force the
optimal query plan.  Although I don't have plans to hack on JIT code but
reports may encourage a few developers to propose changes in this area.


[1] https://dba.stackexchange.com/a/264969
[2] https://www.postgresql.org/docs/current/jit-decision.html
[3] https://www.postgresql.org/message-id/CAApHDvoq5VhV%3D2euyjgBN2bC8Bds9Dtr0bG7R%3DreeefJWKJRXA%40mail.gmail.com


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/