If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the
partition relations dummy and thus doesn't set any (dummy) paths in the
partition relations. The lack of paths in the partitions means that we can
not use partition-wise join while joining this table with some other similarly
partitioned table as the partitions do not have any paths that child-joins can
use. This means that we can not create partition relations for such a join and
thus can not consider the join to be partitioned. This doesn't matter much when
the dummy relation is the outer relation, since the resultant join is also
dummy. But when the dummy relation is inner relation, the resultant join is not
dummy and can be considered to be partitioned with same partitioning scheme as
the outer relation to be joined with other similarly partitioned table. Not
having paths in the partitions deprives us of this future optimization.
Without partition-wise join, not setting dummy paths in the partition relations
makes sense, since those do not have any use. But with partition-wise join that
changes.
If we always mark the partitions dummy, that effort may get wasted if the
partitioned table doesn't participate in the partition-wise join. A possible
solution would be to set the partitions dummy when only the partitioned table
participates in the join, but that happens during make_join_rel(), much after
we have set up the simple relations. So, I am not sure, whether that's a good
option. But I am open to suggestions.
What if we always mark the partition relations of a dummy partitioned table
dummy? I tried attached path on a thousand partition table, the planning time
increased by 3-5%. That doesn't look that bad for a thousand partitions.
Any other options/comments?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index f087ddb..4af95b9 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -421,7 +421,7 @@ static void
set_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
Index rti, RangeTblEntry *rte)
{
- if (IS_DUMMY_REL(rel))
+ if (IS_DUMMY_REL(rel) && !rte->inh)
{
/* We already proved the relation empty, so nothing more to do */
}
@@ -1244,6 +1244,8 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
/*
* Compute the child's access paths.
*/
+ if (IS_DUMMY_REL(rel))
+ set_dummy_rel_pathlist(childrel);
set_rel_pathlist(root, childrel, childRTindex, childRTE);
/*
@@ -1258,6 +1260,12 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
live_childrels = lappend(live_childrels, childrel);
}
+ if (!live_childrels)
+ {
+ Assert(IS_DUMMY_REL(rel));
+ return;
+ }
+
/* Add paths to the "append" relation. */
add_paths_to_append_rel(root, rel, live_childrels);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
