diff --git a/src/backend/utils/cache/plancache.c b/src/backend/utils/cache/plancache.c
index 853c1f6..274b463 100644
--- a/src/backend/utils/cache/plancache.c
+++ b/src/backend/utils/cache/plancache.c
@@ -1090,10 +1090,13 @@ cached_plan_cost(CachedPlan *plan, bool include_planner)
 			 * in the number of relations --- but only until the join collapse
 			 * limits kick in.  Also, while inheritance child relations surely
 			 * add to planning effort, they don't make the join situation
-			 * worse.  So the actual shape of the planning cost curve versus
-			 * number of relations isn't all that obvious.  It will take
-			 * considerable work to arrive at a less crude estimate, and for
-			 * now it's not clear that's worth doing.
+			 * worse.  However, when choosing the join order for partitioned
+			 * tables the effort required to plan the join order is even less
+			 * clear-cut.  Extra effort is put into join planning when
+			 * partition-wise join is in use.  So the actual shape of the
+			 * planning cost curve versus number of relations isn't all that
+			 * obvious.  It will take considerable work to arrive at a less
+			 * crude estimate, and for now it's not clear that's worth doing.
 			 *
 			 * The other big difficulty here is that we don't have any very
 			 * good model of how planning cost compares to execution costs.