Skip to content

Commit dc0eb13

Browse files
committed
Call set_rel_pathlist_hook before generate_gather_paths, not after.
The previous ordering of these steps satisfied the nominal requirement that set_rel_pathlist_hook could editorialize on the whole set of Paths constructed for a base relation. In practice, though, trying to change the set of partial paths was impossible. Adding one didn't work because (a) it was too late to be included in Gather paths made by the core code, and (b) calling add_partial_path after generate_gather_paths is unsafe, because it might try to delete a path it thinks is dominated, but that is already embedded in some Gather path(s). Nor could the hook safely remove partial paths, for the same reason that they might already be embedded in Gathers. Better to call extensions first, let them add partial paths as desired, and then gather. In v11 and up, we already doubled down on that ordering by postponing gathering even further for single-relation queries; so even if the hook wished to editorialize on Gather path construction, it could not. Report and patch by KaiGai Kohei. Back-patch to 9.6 where Gather paths were added. Discussion: https://postgr.es/m/CAOP8fzahwpKJRTVVTqo2AE=mDTz_efVzV6Get_0=U3SO+-ha1A@mail.gmail.com
1 parent 0d7d71b commit dc0eb13

File tree

2 files changed

+19
-13
lines changed

2 files changed

+19
-13
lines changed

doc/src/sgml/custom-scan.sgml

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,8 +37,9 @@
3737
<para>
3838
A custom scan provider will typically add paths for a base relation by
3939
setting the following hook, which is called after the core code has
40-
generated what it believes to be the complete and correct set of access
41-
paths for the relation.
40+
generated all the access paths it can for the relation (except for
41+
Gather paths, which are made after this call so that they can use
42+
partial paths added by the hook):
4243
<programlisting>
4344
typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
4445
RelOptInfo *rel,

src/backend/optimizer/path/allpaths.c

Lines changed: 16 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -478,24 +478,29 @@ set_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
478478
}
479479
}
480480

481-
/*
482-
* If this is a baserel, consider gathering any partial paths we may have
483-
* created for it. (If we tried to gather inheritance children, we could
484-
* end up with a very large number of gather nodes, each trying to grab
485-
* its own pool of workers, so don't do this for otherrels. Instead,
486-
* we'll consider gathering partial paths for the parent appendrel.)
487-
*/
488-
if (rel->reloptkind == RELOPT_BASEREL)
489-
generate_gather_paths(root, rel);
490-
491481
/*
492482
* Allow a plugin to editorialize on the set of Paths for this base
493483
* relation. It could add new paths (such as CustomPaths) by calling
494-
* add_path(), or delete or modify paths added by the core code.
484+
* add_path(), or add_partial_path() if parallel aware. It could also
485+
* delete or modify paths added by the core code.
495486
*/
496487
if (set_rel_pathlist_hook)
497488
(*set_rel_pathlist_hook) (root, rel, rti, rte);
498489

490+
/*
491+
* If this is a baserel, we should normally consider gathering any partial
492+
* paths we may have created for it. We have to do this after calling the
493+
* set_rel_pathlist_hook, else it cannot add partial paths to be included
494+
* here.
495+
*
496+
* However, if this is an inheritance child, skip it. Otherwise, we could
497+
* end up with a very large number of gather nodes, each trying to grab
498+
* its own pool of workers. Instead, we'll consider gathering partial
499+
* paths for the parent appendrel.
500+
*/
501+
if (rel->reloptkind == RELOPT_BASEREL)
502+
generate_gather_paths(root, rel);
503+
499504
/* Now find the cheapest of the paths for this rel */
500505
set_cheapest(rel);
501506

0 commit comments

Comments
 (0)