From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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-29 23:48:21 |
Message-ID: | 121716.1648597701@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 30 Mar 2022 at 12:16, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> FWIW, that doesn't seem quite right - won't it stop JITing e.g. on the inner
>> side of a nested loop, just because it's cheap, even though that's where the
>> bulk of the benefits comes from?
> Yeah, I think the total cost would need to be multiplied by the number
> of times we expect to call that part of the plan. I've not yet sat
> down to figure out if that's easy/cheap or hard/costly information to
> obtain.
As long as you don't need the info till the end of planning, it should be
reasonably simple to determine. I'm not sure if we actually record the
expected number of loops in the plan tree today, but the costing
mechanisms certainly estimate that along the way, so we could store it
if need be.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2022-03-29 23:51:26 | Re: Temporary tables versus wraparound... again |
Previous Message | Andres Freund | 2022-03-29 23:43:28 | Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset |