postgres.git / summary / log / commit / refs

commit    dc47beacaa0b0ad13d7ccd77399cccc98027964d
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Tue Mar 24 20:17:26 2026 +0000

    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


 src/backend/optimizer/path/joinpath.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 044560da7bf..713283a73aa 100644
--- 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;
 
 	/*


[parent: 9ba3ec076a68]