Re: JIT compilation per plan node
От | David Rowley |
---|---|
Тема | Re: JIT compilation per plan node |
Дата | |
Msg-id | CAApHDvrTm43WcB5kL0r2+ZRS=_RR4Biq=2g6bZuxNWmY7u0hRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JIT compilation per plan node (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Thanks for chipping in here. On Fri, 15 Mar 2024 at 08:14, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: