Re: Change default of jit to off
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Pierre Ducroquet <p.psql@pinaraf.info>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas@vondra.me>, Jelte Fennema-Nio <postgres@jeltef.nl>, Greg Sabino Mullane <htamfids@gmail.com>, Adrien Nayrat <adrien.nayrat@anayrat.info>, Christoph Berg <myon@debian.org>, Euler Taveira <euler@eulerto.com>, Álvaro 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>
Date: 2026-03-24T21:56:39Z
Lists: pgsql-hackers
Hi, On 2026-03-23 06:33:33 +0000, Pierre Ducroquet wrote: > Le vendredi 20 mars 2026 à 5:25 PM, Tom Lane <tgl@sss.pgh.pa.us> a écrit : > > > Tomas Vondra <tomas@vondra.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? 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
jit: Change the default to off.
- 7f8c88c2b872 19 (unreleased) landed