get_memoize_path: Don't exit quickly when PGS_NESTLOOP_PLAIN is unset.

This function exits early in the case where the number of inner rows
is estimated to be less than 2, on the theory that in that case a
Nested Loop with inner Memoize must lose to a plain Nested Loop.
But since commit 4020b370f214315b8c10430301898ac21658143f it's
possible for a plain Nested Loop to be disabled, while a Nested Loop
with inner Memoize is still enabled. In that case, this reasoning
is not valid, so adjust the code not to exit early in that case.

This issue was revealed by a test_plan_advice failure on buildfarm
member skink, where NESTED_LOOP_MEMOIZE() couldn't be enforced on
replanning due to this early exit.

Discussion: http://postgr.es/m/CA+TgmoZUN8FT1Ah=m6Uis5bHa4FUa+_hMDWtcABG17toEfpiUg@mail.gmail.com

diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 044560da7bf7a9e2e417b1a783793fc2096db8c8..713283a73aa414b66747e7ec28933cd831f2abc6 100644 (file)
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -729,8 +729,13 @@ get_memoize_path(PlannerInfo *root, RelOptInfo *innerrel,
         * than one inner scan.  The first scan is always going to be a cache
         * miss.  This would likely fail later anyway based on costs, so this is
         * really just to save some wasted effort.
+        *
+        * However, if the "plain nested loop" strategy is disabled, then it is no
+        * longer certain that any path we'd construct here would lose on cost.
+        * So, in that case, continue and let cost comparison sort things out.
         */
-       if (outer_path->parent->rows < 2)
+       if (outer_path->parent->rows < 2 &&
+               (extra->pgs_mask & PGS_NESTLOOP_PLAIN) != 0)
                return NULL;
 
        /*