Re: Add parameter jit_warn_above_fraction - Mailing list pgsql-hackers

From David Rowley
Subject Re: Add parameter jit_warn_above_fraction
Date
Msg-id CAApHDvpfvFBP-=RrY3Jx6eaLYG-mUMLhhss7LLpB6HsAesFsDQ@mail.gmail.com
Whole thread Raw
In response to Re: Add parameter jit_warn_above_fraction  (Andres Freund <andres@anarazel.de>)
Responses Re: Add parameter jit_warn_above_fraction  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, 30 Mar 2022 at 13:20, Andres Freund <andres@anarazel.de> wrote:
> I wonder whether it'd make sense to combine that with awareness of a few plan
> types that can lead to large portions of child nodes never being executed. One
> the case where the current behaviour is the worst is runtime partition pruning
> in append - we compile expressions for whole subtrees that will never be
> executed. We should be much more hesitant to compile there compared to a
> cheap-ish node that we know will be executed as part of a large expensive part
> of the plan tree.

I think that's also a problem but I think that might be better fixed
another way.

There is a patch [1] around that seems to change things to compile JIT
on-demand.  I've not looked at the patch but imagine the overhead
might be kept minimal by initially setting the evalfunc to compile and
run, then set it to just run the compiled Expr for subsequent
executions. Maybe nodes below an Append/MergeAppend with run-time
pruning could compile on-demand and other nodes up-front.  Or maybe
there's no problem with making everything on-demand.

David

[1] https://commitfest.postgresql.org/37/3071/



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: remove reset_shared()
Next
From: Masahiko Sawada
Date:
Subject: Re: logical replication empty transactions