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? We should add the function deduplication pass for O0, to reduce the cost of tuple deforming when accessing many partitions, but in my measurements that isn't the critical path right now. Greetings, Andres Freund
