Re: JIT compilation per plan node - Mailing list pgsql-hackers

From David Rowley
Subject Re: JIT compilation per plan node
Date
Msg-id CAApHDvo6pXsHKyfsYgVqWDea1rYB_W7qrSMebcUxYQNv1QFRbw@mail.gmail.com
Whole thread Raw
In response to Re: JIT compilation per plan node  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Tue, 20 Feb 2024 at 23:04, Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 2/20/24 06:38, David Rowley wrote:
> > On Tue, 20 Feb 2024 at 18:31, Tom Lane <tgl@sss.pgh.pa.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.

I don't believe so as he talked about the fact that the JIT cycles
would drown out the tree walk.  There are no JIT cycles when the cost
threshold isn't met, but we still incur the cost of walking the plan
tree.

David



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: table inheritance versus column compression and storage settings
Next
From: Tomas Vondra
Date:
Subject: Re: JIT compilation per plan node