Re: On disable_cost

On Fri, Aug 2, 2024 at 9:13 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I now think neither of us got it right. I now think what you'd need to
> do to be aligned to the current behaviour is have
> initial_cost_nestloop() add the disabled_nodes for the join's subnodes
> *only* and have final_cost_nestloop() add the additional
> disabled_nodes if enable_nestloop = off. That way you maintain the
> existing behaviour of not optimising for disabled node types and don't
> risk plan changes if the final cost comes out cheaper than the initial
> cost.

All three initial_cost_XXX functions have a comment that says "This
must quickly produce lower-bound estimates of the path's startup and
total costs," i.e. the final cost should never be cheaper. I'm pretty
sure that it was the design intention here that no path ever gets
rejected at the initial cost stage that would have been accepted at
the final cost stage.

(You can also see, as a matter of implementation, that they extract
the startup_cost and run_cost from the workspace and then add to those
values.)

--
Robert Haas
EDB: http://www.enterprisedb.com