Re: bad JIT decision

From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: bad JIT decision
Date: 2020-07-24 22:46:35
Message-ID: 9408F5F7-AD97-4E31-94BD-DAB5112E30F3@elevated-dev.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Jul 24, 2020, at 4:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 they were 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 time like 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 I think that with different variations of the parameters coming in to the query, that for the slower versions (more partitions requiring actual scans), inlining will help. Slowing down the fastest while speeding up the slower is a trade off we can take.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Ribe 2020-07-24 22:49:19 is JIT available
Previous Message David Rowley 2020-07-24 22:42:56 Re: bad JIT decision