diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index e42ef98..caa691c 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -574,17 +574,17 @@ set_rel_consider_parallel(PlannerInfo *root, RelOptInfo *rel,
 
 			/*
 			 * There's no intrinsic problem with scanning a subquery-in-FROM
-			 * (as distinct from a SubPlan or InitPlan) in a parallel worker.
-			 * If the subquery doesn't happen to have any parallel-safe paths,
-			 * then flagging it as consider_parallel won't change anything,
-			 * but that's true for plain tables, too.  We must set
-			 * consider_parallel based on the rel's own quals and targetlist,
-			 * so that if a subquery path is parallel-safe but the quals and
-			 * projection we're sticking onto it are not, we correctly mark
-			 * the SubqueryScanPath as not parallel-safe.  (Note that
+			 * (as distinct from a SubPlan or InitPlan) in a parallel worker
+			 * if it is parallel-safe.  We must set consider_parallel based
+			 * on the rel's own quals and targetlist, so that if a subquery
+			 * path is parallel-safe but the quals and projection we're
+			 * sticking onto it are not, we correctly mark the
+			 * SubqueryScanPath as not parallel-safe.  (Note that
 			 * set_subquery_pathlist() might push some of these quals down
 			 * into the subquery itself, but that doesn't change anything.)
 			 */
+			if (!is_parallel_safe(root, (Node *) rte->subquery))
+				return;
 			break;
 
 		case RTE_JOIN: