Re: bad JIT decision - Mailing list pgsql-general

From Scott Ribe
Subject Re: bad JIT decision
Date
Msg-id 9408F5F7-AD97-4E31-94BD-DAB5112E30F3@elevated-dev.com
Whole thread Raw
In response to Re: bad JIT decision  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> On Jul 24, 2020, at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yeah.  I'm fairly convinced that the v12 defaults are far too low,
> because we are constantly seeing complaints of this sort.


They are certainly too low for our case; not sure if for folks who are not partitioning if they're way too low.

The passive-aggressive approach would really not be good general advice for you, but I'm actually glad that in our case
theywere low enough to get our attention early ;-) 

I think I will disable optimization, because with our partitioning scheme we will commonly see blow ups of optimization
timelike this one. 

The inlining time in this case is still much more than the query, but it is low enough to not be noticed by users, and
Ithink that with different variations of the parameters coming in to the query, that for the slower versions (more
partitionsrequiring actual scans), inlining will help. Slowing down the fastest while speeding up the slower is a trade
offwe can take. 


pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: bad JIT decision
Next
From: Scott Ribe
Date:
Subject: is JIT available