Re: JIT compilation per plan node

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JIT compilation per plan node
Date: 2024-05-14 11:31:13
Message-ID: CAGECzQR80bSRheQVFDAxyQqyMpSeHGiJ3YQWhFBr2+ATJRjSoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 14 May 2024 at 10:19, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Here's a plan where the total cost of a subnode is greater than the
> total cost of the top node:

Ah I didn't realize it was possible for that to happen. **reads up on
plan costs**

This actually makes me think that using total_cost of the sub-nodes is
not the enough to determine determining if the node should be JITet.
We wouldn't want to start jitting plans like this, i.e. introducing
all the JIT setup overhead for just a single row:

set max_parallel_workers_per_gather=0;
create table t0 as select a from generate_Series(1,1000000)a;
analyze t0;
explain select a+a*a+a*a+a from t0 limit 1;
QUERY PLAN
-----------------------------------------------------
Limit (cost=0.00..0.03 rows=1 width=4)
-> Seq Scan on t0 (cost=0.00..26980.00 rows=1000000 width=4)

An easy way to work around that issue I guess is by using the minimum
total_cost of all the total_costs from the current sub-node up to the
root node. The current minimum could be passed along as a part of the
context I guess.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-05-14 11:41:06 Re: elog/ereport VS misleading backtrace_function function address
Previous Message Aleksander Alekseev 2024-05-14 11:18:33 Re: Postgres and --config-file option