Re: Change default of jit to off

From: Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Andres Freund <andres(at)anarazel(dot)de>, 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-23 06:33:33
Message-ID: gPNlX1QTDtJW2Cyi3fA2OGFvoIybkehUYKCHCe2r3Ujm_0y9V1T13CPI2MA6RyPhLi8zNwNczq1DNrbh1l47eVn6tOwz-qzG2yXw_XtptTQ=@pinaraf.info
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2026-03-23 07:00:50 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Chao Li 2026-03-23 06:30:28 Re: Bug in pg_get_aios()