Dept of second thoughts: don't try to push LIMIT below a SRF.

tglsfdc · tglsfdc · commit 48c348f86ce0 · 2010-11-18T11:54:34.000-05:00
If we have Limit-&gt;Result-&gt;Sort, the Result might be projecting a tlist
that contains a set-returning function.  If so, it's possible for the
SRF to sometimes return zero rows, which means we could need to fetch
more than N rows from the Sort in order to satisfy LIMIT N.
So top-N sorting cannot be used in this scenario.
diff --git a/src/backend/executor/nodeLimit.c b/src/backend/executor/nodeLimit.c
@@ -23,6 +23,7 @@
 
 #include "executor/executor.h"
 #include "executor/nodeLimit.h"
+#include "nodes/nodeFuncs.h"
 
 static void recompute_limits(LimitState *node);
 static void pass_down_bound(LimitState *node, PlanState *child_node);
@@ -344,7 +345,19 @@ pass_down_bound(LimitState *node, PlanState *child_node)
 	}
 	else if (IsA(child_node, ResultState))
 	{
-		if (outerPlanState(child_node))
+		/*
+		 * An extra consideration here is that if the Result is projecting
+		 * a targetlist that contains any SRFs, we can't assume that every
+		 * input tuple generates an output tuple, so a Sort underneath
+		 * might need to return more than N tuples to satisfy LIMIT N.
+		 * So we cannot use bounded sort.
+		 *
+		 * If Result supported qual checking, we'd have to punt on seeing
+		 * a qual, too.  Note that having a resconstantqual is not a
+		 * showstopper: if that fails we're not getting any rows at all.
+		 */
+		if (outerPlanState(child_node) &&
+			!expression_returns_set((Node *) child_node->plan->targetlist))
 			pass_down_bound(node, outerPlanState(child_node));
 	}
 }
