Обсуждение: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

Поиск
Список
Период
Сортировка

Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

От
Andy Fan
Дата:
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.

Вложения

Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

От
Zhang Mingli
Дата:
HI, 


On Apr 10, 2023, 16:35 +0800, Andy Fan <zhihui.fan1213@gmail.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

Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

От
Andy Fan
Дата:


On Mon, Apr 10, 2023 at 9:56 PM Zhang Mingli <zmlpostgres@gmail.com> wrote:

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?

 
Thanks for the suggestion,  the v2 has fixed the indent issue and I did
something about parallel append.  Besides that,  I restrict the changes
happens under bms_equal(rel->relids, root->all_query_rels), which may
make this patch safer. 


--
Best Regards
Andy Fan
Вложения