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