Re: make add_paths_to_append_rel aware of startup cost

On Thu, 7 Sept 2023 at 04:37, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> Currently add_paths_to_append_rel overlooked the startup cost for creating
> append path, so it may have lost some optimization chances. After a glance,
> the following 4 identifiers can be impacted.

> - We shouldn't do the optimization if there are still more tables to join,
> the reason is similar to has_multiple_baserels(root) in
> set_subquery_pathlist. But the trouble here is we may inherit multiple
> levels to build an appendrel, so I have to keep the 'top_relids' all the
> time and compare it with PlannerInfo.all_baserels. If they are the same,
> then it is the case we want to optimize.

I think you've likely gone to the trouble of trying to determine if
there are any joins pending because you're considering using a cheap
startup path *instead* of the cheapest total path and you don't want
to do that when some join will cause all the rows to be read thus
making the plan more expensive if a cheap startup path was picked.

Instead of doing that, why don't you just create a completely new
AppendPath containing all the cheapest_startup_paths and add that to
the append rel. You can optimise this and only do it when
rel->consider_startup is true.

Does the attached do anything less than what your patch does?

David