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 <[email protected]> a écrit :
>>
>>> Tomas Vondra <[email protected]> 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/[email protected]
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
