Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

HI,

On Apr 10, 2023, 16:35 +0800, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, wrote:
> When I am working on "Pushing limit into subqueries of a union" [1], I
> found we already have a great infrastructure to support this. For a query
> like
>
> subquery-1 UNION ALL subquery-2 LIMIT 3;
>
> We have considered the root->tuple_fraction when planning the subqueries
> without an extra Limit node as an overhead. But the reason it doesn't work
> in my real case is flatten_simple_union_all flat the union all subqueries
> into append relation and we didn't handle the root->tuple_fraction during
> add_paths_to_append_rel.
>
> Given the below query for example:
> explain analyze
> (select * from tenk1 order by hundred)
> union all
> (select * from tenk2 order by hundred)
> limit 3;
>
> Without the patch: Execution Time: 7.856 ms
> with the patch:  Execution Time: 0.224 ms
>
> Any suggestion is welcome.
>
> [1] https://www.postgresql.org/message-id/11228.1118365833%40sss.pgh.pa.us
>
> --
> Best Regards
> Andy Fan

There is spare indent at else if.

- if (childrel->pathlist != NIL &&
+ if (cheapest_startup_path && cheapest_startup_path->param_info == NULL)
+ accumulate_append_subpath(cheapest_startup_path,
+   &subpaths, NULL);
+ else if (childrel->pathlist != NIL &&
  childrel->cheapest_total_path->param_info == NULL)
  accumulate_append_subpath(childrel->cheapest_total_path,
    &subpaths, NULL);

Could we also consider tuple_fraction in partial_pathlist for  parallel append?

Regards,
Zhang Mingli