On Tue, 14 May 2024 at 10:19, David Rowley 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
On Tue, 14 May 2024 at 19:56, Jelte Fennema-Nio wrote:
> I'm not saying I'd prefer the extra walk, but I don't think you'd need
> to do this extra walk for all plans. Afaict you could skip the extra
> walk when top_plan->total_cost < jit_above_cost. i.e. only doing the
> extra walk to determine
On Tue, 20 Feb 2024 at 06:38, David Rowley wrote:
>
> On Tue, 20 Feb 2024 at 18:31, Tom Lane wrote:
> > FWIW, I seriously doubt that an extra walk of the plan tree is even
> > measurable compared to the number of cycles JIT compilation will
> > expend if it's called. So I don't buy your
On Fri, 15 Mar 2024 at 10:13, Tomas Vondra
wrote:
> To clarify, I think the patch is a step in the right direction, and a
> meaningful improvement. It may not be the perfect solution we imagine
> (but who knows how far we are from that), but AFAIK moving these
> decisions to the node level is
On 3/14/24 20:14, Robert Haas wrote:
> On Tue, Feb 20, 2024 at 5:31 AM Tomas Vondra
> wrote:
>> I certainly agree that the current JIT costing is quite crude, and we've
>> all seen cases where the decision turns out to not be great. And I think
>> the plan to make the decisions at the node
Thanks for chipping in here.
On Fri, 15 Mar 2024 at 08:14, Robert Haas 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
>
On Tue, Feb 20, 2024 at 5:31 AM Tomas Vondra
wrote:
> I certainly agree that the current JIT costing is quite crude, and we've
> all seen cases where the decision turns out to not be great. And I think
> the plan to make the decisions at the node level makes sense, so +1 to
> that in general.
On 2/20/24 06:14, David Rowley wrote:
> On Tue, 20 Feb 2024 at 05:26, Tomas Vondra
> wrote:
>> I doubt CreatePlanContext is a great way to achieve this. For one, it
>> breaks the long-standing custom that PlannerInfo is the first parameter,
>> usually followed by RelOptInfo, etc.
On Tue, 20 Feb 2024 at 23:04, Tomas Vondra
wrote:
>
> On 2/20/24 06:38, David Rowley wrote:
> > On Tue, 20 Feb 2024 at 18:31, Tom Lane wrote:
> >> FWIW, I seriously doubt that an extra walk of the plan tree is even
> >> measurable compared to the number of cycles JIT compilation will
> >> expend
On 2/20/24 06:38, David Rowley wrote:
> On Tue, 20 Feb 2024 at 18:31, Tom Lane wrote:
>> FWIW, I seriously doubt that an extra walk of the plan tree is even
>> measurable compared to the number of cycles JIT compilation will
>> expend if it's called. So I don't buy your argument here.
>> We
On Tue, 20 Feb 2024 at 18:31, Tom Lane wrote:
> FWIW, I seriously doubt that an extra walk of the plan tree is even
> measurable compared to the number of cycles JIT compilation will
> expend if it's called. So I don't buy your argument here.
> We would be better off to do this in a way that's
David Rowley writes:
> On Tue, 20 Feb 2024 at 05:26, Tomas Vondra
> wrote:
>> Wouldn't it be simpler to just build the plan as we do now, and then
>> have an expression_tree_walker that walks the complete plan top-down,
>> inspects the nodes, enables JIT where appropriate and so on? That can
>>
On Tue, 20 Feb 2024 at 05:26, Tomas Vondra
wrote:
> I doubt CreatePlanContext is a great way to achieve this. For one, it
> breaks the long-standing custom that PlannerInfo is the first parameter,
> usually followed by RelOptInfo, etc. CreatePlanContext is added to some
> functions (but not all),
Hi Melih,
On 1/2/24 20:50, Melih Mutlu wrote:
> Hi hackers,
>
> After discussing this with David offlist, I decided to reinitiate this
> discussion that has already been raised and discussed several times in the
> past. [1] [2]
>
> Currently, if JIT is enabled, the decision for JIT compilation
14 matches
Mail list logo
