Re: JIT compilation per plan node

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JIT compilation per plan node
Date: 2024-02-20 10:04:21
Message-ID: bd1f1eeb-e0e5-4258-b7e2-e66b4beb37a8@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/20/24 06:38, David Rowley wrote:
> On Tue, 20 Feb 2024 at 18:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> FWIW, I seriously doubt that an extra walk of the plan tree is even
>> measurable compared to the number of cycles JIT compilation will
>> expend if it's called. So I don't buy your argument here.
>> We would be better off to do this in a way that's clean and doesn't
>> add overhead for non-JIT-enabled builds.
>
> The extra walk of the tree would need to be done for every plan, not
> just the ones where we do JIT. I'd rather find a way to not add this
> extra plan tree walk, especially since the vast majority of cases on
> an average instance won't be doing any JIT.
>

I believe Tom was talking about non-JIT-enabled-builds, i.e. builds that
either don't support JIT at all, or where jit=off. Those would certainly
not need the extra walk.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Quan Zongliang 2024-02-20 10:07:46 Change the bool member of the Query structure to bits
Previous Message David Rowley 2024-02-20 10:02:05 Re: Add bump memory context type and use it for tuplesorts