| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(at)vondra(dot)me>, 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-24 21:56:39 |
| Message-ID: | vhiu76rnwynmtmm3jbkettfelj5l2jtnbkwm7szpiyjbyrmd44@3gdapm3mnu3m |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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(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?
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-03-24 21:56:56 | Re: pg_get__*_ddl consolidation |
| Previous Message | Nathan Bossart | 2026-03-24 21:47:30 | Re: Fixes inconsistent behavior in vacuum when it processes multiple relations |