On Thu, 7 Sept 2023 at 04:37, Andy Fan <zhihui.fan1213@gmail.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
