database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-04 20:11:56 +03:00
Code Activity

Track the number of presorted outer pathkeys in MergePath

Browse Source 
When creating an explicit Sort node for the outer path of a mergejoin,
we need to determine the number of presorted keys of the outer path to
decide whether explicit incremental sort can be applied.  Currently,
this is done by repeatedly calling pathkeys_count_contained_in.

This patch caches the number of presorted outer pathkeys in MergePath,
allowing us to save several calls to pathkeys_count_contained_in.  It
can be considered a complement to the changes in commit 828e94c9d.

Reported-by: David Rowley <dgrowleyml@gmail.com>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tender Wang <tndrwang@gmail.com>
Discussion: https://postgr.es/m/CAApHDvqvBireB_w6x8BN5txdvBEHxVgZBt=rUnpf5ww5P_E_ww@mail.gmail.com
This commit is contained in:
Richard Guo
2025-05-08 18:21:32 +09:00
parent 773db22269
commit c06e909c26
8 changed files with 104 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/backend/optimizer/path/joinpath.c
View File

@@ -1042,6 +1042,7 @@ try_mergejoin_path(PlannerInfo *root,
bool is_partial)
{
Relids required_outer;
int outer_presorted_keys = 0;
JoinCostWorkspace workspace;
if (is_partial)
@@ -1087,9 +1088,16 @@ try_mergejoin_path(PlannerInfo *root,
/*
* If the given paths are already well enough ordered, we can skip doing
* an explicit sort.
*
* We need to determine the number of presorted keys of the outer path to
* decide whether explicit incremental sort can be applied when
* outersortkeys is not NIL. We do not need to do the same for the inner
* path though, as incremental sort currently does not support
* mark/restore.
*/
if (outersortkeys &&
pathkeys_contained_in(outersortkeys, outer_path->pathkeys))
pathkeys_count_contained_in(outersortkeys, outer_path->pathkeys,
&outer_presorted_keys))
outersortkeys = NIL;
if (innersortkeys &&
pathkeys_contained_in(innersortkeys, inner_path->pathkeys))
@@ -1101,6 +1109,7 @@ try_mergejoin_path(PlannerInfo *root,
initial_cost_mergejoin(root, &workspace, jointype, mergeclauses,
outer_path, inner_path,
outersortkeys, innersortkeys,
outer_presorted_keys,
extra);
if (add_path_precheck(joinrel, workspace.disabled_nodes,
@@ -1120,7 +1129,8 @@ try_mergejoin_path(PlannerInfo *root,
required_outer,
mergeclauses,
outersortkeys,
innersortkeys));
innersortkeys,
outer_presorted_keys));
}
else
{
@@ -1146,6 +1156,7 @@ try_partial_mergejoin_path(PlannerInfo *root,
JoinType jointype,
JoinPathExtraData *extra)
{
int outer_presorted_keys = 0;
JoinCostWorkspace workspace;
/*
@@ -1159,9 +1170,16 @@ try_partial_mergejoin_path(PlannerInfo *root,
/*
* If the given paths are already well enough ordered, we can skip doing
* an explicit sort.
*
* We need to determine the number of presorted keys of the outer path to
* decide whether explicit incremental sort can be applied when
* outersortkeys is not NIL. We do not need to do the same for the inner
* path though, as incremental sort currently does not support
* mark/restore.
*/
if (outersortkeys &&
pathkeys_contained_in(outersortkeys, outer_path->pathkeys))
pathkeys_count_contained_in(outersortkeys, outer_path->pathkeys,
&outer_presorted_keys))
outersortkeys = NIL;
if (innersortkeys &&
pathkeys_contained_in(innersortkeys, inner_path->pathkeys))
@@ -1173,6 +1191,7 @@ try_partial_mergejoin_path(PlannerInfo *root,
initial_cost_mergejoin(root, &workspace, jointype, mergeclauses,
outer_path, inner_path,
outersortkeys, innersortkeys,
outer_presorted_keys,
extra);
if (!add_partial_path_precheck(joinrel, workspace.disabled_nodes,
@@ -1193,7 +1212,8 @@ try_partial_mergejoin_path(PlannerInfo *root,
NULL,
mergeclauses,
outersortkeys,
innersortkeys));
innersortkeys,
outer_presorted_keys));
}
/*