Thread: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel
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.
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.
Attachment
Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel
From
Zhang Mingli
Date:
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
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.
I have added this into https://commitfest.postgresql.org/43/4270/
Best Regards
Andy Fan