Skip to content

Commit a6ea727

Browse files
committed
Propagate lateral-reference information to indirect descendant relations.
create_lateral_join_info() computes a bunch of information about lateral references between base relations, and then attempts to propagate those markings to appendrel children of the original base relations. But the original coding neglected the possibility of indirect descendants (grandchildren etc). During v11 development we noticed that this was wrong for partitioned-table cases, but failed to realize that it was just as wrong for any appendrel. While the case can't arise for appendrels derived from traditional table inheritance (because we make a flat appendrel for that), nested appendrels can arise from nested UNION ALL subqueries. Failure to mark the lower-level relations as having lateral references leads to confusion in add_paths_to_append_rel about whether unparameterized paths can be built. It's not very clear whether that leads to any user-visible misbehavior; the lack of field reports suggests that it may cause nothing worse than minor cost misestimation. Still, it's a bug, and it leads to failures of Asserts that I intend to add later. To fix, we need to propagate information from all appendrel parents, not just those that are RELOPT_BASERELs. We can still do it in one pass, if we rely on the append_rel_list to be ordered with ancestor relationships before descendant ones; add assertions checking that. While fixing this, we can make a small performance improvement by traversing the append_rel_list just once instead of separately for each appendrel parent relation. Noted while investigating bug #15613, though this patch does not fix that (which is why I'm not committing the related Asserts yet). Discussion: https://postgr.es/m/3951.1549403812@sss.pgh.pa.us
1 parent 1f28906 commit a6ea727

File tree

1 file changed

+33
-22
lines changed

1 file changed

+33
-22
lines changed

src/backend/optimizer/plan/initsplan.c

Lines changed: 33 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -417,6 +417,7 @@ void
417417
create_lateral_join_info(PlannerInfo *root)
418418
{
419419
bool found_laterals = false;
420+
Relids prev_parents PG_USED_FOR_ASSERTS_ONLY = NULL;
420421
Index rti;
421422
ListCell *lc;
422423

@@ -625,33 +626,43 @@ create_lateral_join_info(PlannerInfo *root)
625626
* every child anyway, and there's no value in forcing extra
626627
* reparameterize_path() calls. Similarly, a lateral reference to the
627628
* parent prevents use of otherwise-movable join rels for each child.
629+
*
630+
* It's possible for child rels to have their own children, in which case
631+
* the topmost parent's lateral info must be propagated all the way down.
632+
* This code handles that case correctly so long as append_rel_list has
633+
* entries for child relationships before grandchild relationships, which
634+
* is an okay assumption right now, but we'll need to be careful to
635+
* preserve it. The assertions below check for incorrect ordering.
628636
*/
629-
for (rti = 1; rti < root->simple_rel_array_size; rti++)
637+
foreach(lc, root->append_rel_list)
630638
{
631-
RelOptInfo *brel = root->simple_rel_array[rti];
639+
AppendRelInfo *appinfo = (AppendRelInfo *) lfirst(lc);
640+
RelOptInfo *parentrel = root->simple_rel_array[appinfo->parent_relid];
641+
RelOptInfo *childrel = root->simple_rel_array[appinfo->child_relid];
632642

633-
if (brel == NULL || brel->reloptkind != RELOPT_BASEREL)
643+
/*
644+
* If we're processing a subquery of a query with inherited target rel
645+
* (cf. inheritance_planner), append_rel_list may contain entries for
646+
* tables that are not part of the current subquery and hence have no
647+
* RelOptInfo. Ignore them. We can ignore dead rels, too.
648+
*/
649+
if (parentrel == NULL || !IS_SIMPLE_REL(parentrel))
634650
continue;
635651

636-
if (root->simple_rte_array[rti]->inh)
637-
{
638-
foreach(lc, root->append_rel_list)
639-
{
640-
AppendRelInfo *appinfo = (AppendRelInfo *) lfirst(lc);
641-
RelOptInfo *childrel;
642-
643-
if (appinfo->parent_relid != rti)
644-
continue;
645-
childrel = root->simple_rel_array[appinfo->child_relid];
646-
Assert(childrel->reloptkind == RELOPT_OTHER_MEMBER_REL);
647-
Assert(childrel->direct_lateral_relids == NULL);
648-
childrel->direct_lateral_relids = brel->direct_lateral_relids;
649-
Assert(childrel->lateral_relids == NULL);
650-
childrel->lateral_relids = brel->lateral_relids;
651-
Assert(childrel->lateral_referencers == NULL);
652-
childrel->lateral_referencers = brel->lateral_referencers;
653-
}
654-
}
652+
/* Verify that children are processed before grandchildren */
653+
#ifdef USE_ASSERT_CHECKING
654+
prev_parents = bms_add_member(prev_parents, appinfo->parent_relid);
655+
Assert(!bms_is_member(appinfo->child_relid, prev_parents));
656+
#endif
657+
658+
/* OK, propagate info down */
659+
Assert(childrel->reloptkind == RELOPT_OTHER_MEMBER_REL);
660+
Assert(childrel->direct_lateral_relids == NULL);
661+
childrel->direct_lateral_relids = parentrel->direct_lateral_relids;
662+
Assert(childrel->lateral_relids == NULL);
663+
childrel->lateral_relids = parentrel->lateral_relids;
664+
Assert(childrel->lateral_referencers == NULL);
665+
childrel->lateral_referencers = parentrel->lateral_referencers;
655666
}
656667
}
657668

0 commit comments

Comments
 (0)