Re: Add parameter jit_warn_above_fraction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add parameter jit_warn_above_fraction
Дата
Msg-id 121716.1648597701@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add parameter jit_warn_above_fraction  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 30 Mar 2022 at 12:16, Andres Freund <andres@anarazel.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Temporary tables versus wraparound... again