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.
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 |