Fix planner's failure to identify multiple hashable ScalarArrayOpExprs

50e17ad28 (v14) and 29f45e299 (v15) made it so the planner could identify
IN and NOT IN clauses which have Const lists as right-hand arguments and
when an appropriate hash function is available for the data types, mark
the ScalarArrayOpExpr as hashable so the executor could execute it more
optimally by building and probing a hash table during expression
evaluation.

These commits both worked correctly when there was only a single
ScalarArrayOpExpr in the given expression being processed by the
planner, but when there were multiple, only the first was checked and any
subsequent ones were not identified, which resulted in less optimal
expression evaluation during query execution for all but the first found
ScalarArrayOpExpr.

Backpatch to 14, where 50e17ad28 was introduced.

Author: David Geier <[email protected]>
Discussion: https://postgr.es/m/29a76f51-97b0-4c07-87b7-ec8e3b5345c9@gmail.com
Backpatch-through: 14

diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index 43dfecfb47fa8f34f66e5bbf77eb1b0ba4640832..4622eaf709f9291ddd16f4ca27dffff46b9753d4 100644 (file)
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -2326,7 +2326,7 @@ convert_saop_to_hashed_saop_walker(Node *node, void *context)
                        /* Looks good. Fill in the hash functions */
                        saop->hashfuncid = lefthashfunc;
                    }
-                   return true;
+                   return false;
                }
            }
            else                /* !saop->useOr */
@@ -2364,7 +2364,7 @@ convert_saop_to_hashed_saop_walker(Node *node, void *context)
                         */
                        saop->negfuncid = get_opcode(negator);
                    }
-                   return true;
+                   return false;
                }
            }
        }