On Thu, 7 Sept 2023 at 04:37, Andy Fan <zhihui.fan1...@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
consider_cheapest_startup_appendpath.patch
Description: Binary data
