From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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-03-14 19:54:18 |
Message-ID: | CAApHDvrTm43WcB5kL0r2+ZRS=_RR4Biq=2g6bZuxNWmY7u0hRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for chipping in here.
On Fri, 15 Mar 2024 at 08:14, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> A slightly subtler way the patch could lose is if the new threshold is
> harder to adjust than the old one. For example, imagine that you have
> a query that does a Cartesian join. That makes the cost of the input
> nodes rather small compared to the cost of the join node, and it also
> means that JITting the inner join child in particular is probably
> rather important. But if you set join_above_cost low enough to JIT
> that node post-patch, then maybe you'll also JIT a bunch of things
> that aren't on the inner side of a nested loop and which might
> therefore not really need JIT. Unless I'm missing something, this is a
> fairly realistic example of where this patch's approach to costing
> could turn out to be painful ... but it's not like the current system
> is pain-free either.
I think this case would be covered as the cost of the inner side of
the join would be multiplied by the estimated outer-side rows.
Effectively, making this part work is the bulk of the patch as we
currently don't know the estimated number of loops of a node during
create plan.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2024-03-14 20:00:06 | Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE |
Previous Message | Amonson, Paul D | 2024-03-14 19:50:46 | RE: Popcount optimization using AVX512 |