Re: bad JIT decision

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
Cc: PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: bad JIT decision
Date: 2020-07-24 22:26:05
Message-ID: CAApHDvoGfCqiF-20k4OLgawyubezBbpBpdfJ0SuphbbK0KEVUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 25 Jul 2020 at 08:46, Scott Ribe <scott_ribe(at)elevated-dev(dot)com> wrote:
> Given the magnitude of the miss in using JIT here, I am wondering: is it possible that the planner does not properly take into account the cost of JIT'ing a function for multiple partitions? Or is it that the planner doesn't have enough info about the restrictiveness of conditions, and is therefore anticipating running the functions against a great many rows?

It does not really take into account the cost of jitting. If the total
plan cost is above the jit threshold then jit is enabled. If not, then
it's disabled.

There are various levels of jit and various thresholds that can be tweaked, see:

select name,setting from pg_settings where name like '%jit%';

But as far as each threshold goes, you either reach it or you don't.
Maybe that can be made better by considering jit in a more cost-based
way rather than by threshold, that way it might be possible to
consider jit per plan node rather than on the query as a whole. e.g,
if you have 1000 partitions and 999 of them have 1 row and the final
one has 1 billion rows, then it's likely a waste of time to jit
expressions for the 999 partitions.

However, for now, you might just want to try raising various jit
thresholds so that it only is enabled for more expensive plans.

David

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Ribe 2020-07-24 22:32:01 Re: bad JIT decision
Previous Message Christophe Pettus 2020-07-24 21:54:21 Re: Row estimates for empty tables