Re: Add parameter jit_warn_above_fraction

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add parameter jit_warn_above_fraction
Date: 2022-03-07 11:56:52
Message-ID: CABUevEyRESc18L5vrPgKeuPX6Ay=Sox=L7aaj8H=v3idH9+D3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 25, 2022 at 5:47 PM Andres Freund <andres(at)anarazel(dot)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(at)anarazel(dot)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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-03-07 11:58:50 Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Previous Message Michael Paquier 2022-03-07 11:36:20 Re: pg_tablespace_location() failure with allow_in_place_tablespaces