From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add parameter jit_warn_above_fraction |
Date: | 2022-03-30 01:30:32 |
Message-ID: | CAApHDvpfvFBP-=RrY3Jx6eaLYG-mUMLhhss7LLpB6HsAesFsDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 30 Mar 2022 at 13:20, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-03-30 01:44:37 | Re: logical replication empty transactions |
Previous Message | Julien Rouhaud | 2022-03-30 01:19:42 | Re: remove reset_shared() |