Re: Add parameter jit_warn_above_fraction - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Add parameter jit_warn_above_fraction
Date
Msg-id CABUevEyRESc18L5vrPgKeuPX6Ay=Sox=L7aaj8H=v3idH9+D3A@mail.gmail.com
Whole thread Raw
In response to Re: Add parameter jit_warn_above_fraction  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Next
From: Michael Paquier
Date:
Subject: Re: pg_tablespace_location() failure with allow_in_place_tablespaces