Re: Change default of jit to off

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Andres Freund <andres(at)anarazel(dot)de>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, Christoph Berg <myon(at)debian(dot)org>, Euler Taveira <euler(at)eulerto(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andreas Karlsson <andreas(at)proxel(dot)se>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Banck <mbanck(at)gmx(dot)net>
Subject: Re: Change default of jit to off
Date: 2026-03-25 22:10:25
Message-ID: d8bb1295-6392-4cba-917d-de7da2b8c8bd@vondra.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/24/26 22:56, Andres Freund wrote:
> Hi,
>
> On 2026-03-23 06:33:33 +0000, Pierre Ducroquet wrote:
>> Le vendredi 20 mars 2026 à 5:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
>>
>>> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>>>> ISTM there's a clear consensus to get this committed for PG19, so
>>>> barring objections I'll take care of that in the next couple days.
>>>> Unless someone else wants to ...
>>>
>>> +1
>>>
>>>> Another option would be to leave that for mid-beta, which is where we
>>>> tweaked the io_method GUCs last year. But we did that to get some
>>>> testing for 'worker' (in case we revert to 'sync'), and we don't need
>>>> that for jit.
>>>
>>> Doesn't seem like something to change mid-beta. If it makes anyone
>>> unhappy, we'd best find out sooner not later.
>>
>> I've not seen any feedback on my "counter"-proposal: switch
>> jit_tuple_deforming to off by default. Sure, for the perfect llvmjit use
>> cases this will reduce the performance benefits, but it will remove most if
>> not all the problematic queries (for instance queries running on many
>> partitions, adding/moving columns leading to explosions in compilation
>> time...) Of course if there are other troublesome situations, I would love
>> being proven wrong.
>
> I doubt that that addresses the problem in any meaningful way. In nearly all
> the cases I've looked at expression compilation completely dominates the cost,
> due to being instantiated for every partition etc. So I'm rather surprised to
> see this claim?
>

That's my understanding too. I did search in the archives for
performance issues related to JIT, and those are the first two I found:

1)
https://www.postgresql.org/message-id/6191e1ee-d548-2a8c-d87d-dab63c05ad2e@code-sourcery.de

2)
https://www.postgresql.org/message-id/flat/LEXPR01MB09897821BA2CDDB70225EF7BE79C0%40LEXPR01MB0989.DEUPRD01.PROD.OUTLOOK.DE

Both have all the JIT stuff enabled, and the timings are dominated by
Optimization:

* Timing: Generation 15.707 ms, Inlining 4.688 ms, Optimization
652.021 ms, Emission 939.556 ms, Total 1611.973 ms

* Timing: Generation 27.833 ms, Inlining 117.093 ms, Optimization
3917.001 ms, Emission 2027.251 ms, Total 6089.177 ms

Or am I mistaken and it could still be due to deforming? It'd be a bit
silly to disable jit_tuple_deforming=off, only to find it's not enough
and have to disable more stuff for PG20.

Furthermore, jit_tuple_deforming is marked as DEVELOPER_OPTIONS, and is
not in the sample. Wouldn't that be a bit confusing/surprising, if we
disable just that, as it's not in the sample?

regards

--
Tomas Vondra

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-25 22:10:43 Re: another autovacuum scheduling thread
Previous Message David Rowley 2026-03-25 22:09:36 Re: Test timings are increasing too fast for cfbot