Re: Add parameter jit_warn_above_fraction

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Add parameter jit_warn_above_fraction
Дата
Msg-id CABUevEyRESc18L5vrPgKeuPX6Ay=Sox=L7aaj8H=v3idH9+D3A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add parameter jit_warn_above_fraction  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, Feb 25, 2022 at 5:47 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-02-25 17:28:41 +0100, Magnus Hagander wrote:
> > On Fri, Feb 25, 2022 at 5:20 PM Andres Freund <andres@anarazel.de> wrote:
> > > On 2022-02-25 16:16:01 +0100, Magnus Hagander wrote:
> > > > This patch adds a configuration parameter jit_warn_above_fraction that
> > > > will cause a warning to be logged if the fraction of time spent on
> > > > doing JIT is bigger than the specified one. For example, this can be
> > > > used to track down those cases where JIT ends up taking 90% of the
> > > > query runtime because of bad estimates...
> > >
> > > Hm. Could it make sense to do this as a auto_explain feature?
> >
> > It could be. But I was looking for something a lot more "light weight"
> > than having to install an extension. But yes, if we wanted to, we
> > could certainly change jit_warn_above_fraction to be
> > auto_explain.log_min_jit_fraction or something like that, and do
> > basically the same thing.  But then, we could also have
> > log_min_duration_statement be part of auto_explain instead, so it's
> > all about where to draw the line :)
>
> I guess it feels a tad on the "too narrow/specific" side of things for the
> general code. We don't have log_min_duration_{parsing,planning,execution}
> either.  But I also get it. So I just wanted to raise it ;)

Oh it's absolutely a valid issue to raise :) In fact, one could
definitely argue that we should have a parameter for auto_explain *as
well*.

It's true we don't have those -- but it's also in my experience a lot
more common to be an issue with JIT. And unfortunately the current
"solution" people tend to apply is to globally disable JIT, and
there's no similar "globally disable parsing or "globally disable
planning" pattern, for obvious reasons.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_tablespace_location() failure with allow_in_place_tablespaces