Re: JIT compilation per plan node - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: JIT compilation per plan node
Date
Msg-id CAGECzQR80bSRheQVFDAxyQqyMpSeHGiJ3YQWhFBr2+ATJRjSoQ@mail.gmail.com
Whole thread Raw
In response to Re: JIT compilation per plan node  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Tue, 14 May 2024 at 10:19, David Rowley <dgrowleyml@gmail.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.



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Postgres and --config-file option
Next
From: Alvaro Herrera
Date:
Subject: Re: elog/ereport VS misleading backtrace_function function address