Copilot commented on code in PR #2417:
URL: https://github.com/apache/age/pull/2417#discussion_r3183651605
##########
regress/expected/cypher_match.out:
##########
@@ -2407,15 +2407,15 @@ SELECT * FROM cypher('cypher_match', $$ MATCH (a
{name:a.name}) MATCH (a {age:a.
SELECT * FROM cypher('cypher_match', $$ MATCH p=(a)-[u {relationship:
u.relationship}]->(b) RETURN p $$) as (a agtype);
a
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- [{"id": 281474976710661, "label": "", "properties": {"age": 4, "name":
"T"}}::vertex, {"id": 4785074604081153, "label": "knows", "end_id":
281474976710666, "start_id": 281474976710661, "properties": {"years": 3,
"relationship": "friends"}}::edge, {"id": 281474976710666, "label": "",
"properties": {"age": 6}}::vertex]::path
[{"id": 281474976710659, "label": "", "properties": {"age": 3, "name":
"orphan"}}::vertex, {"id": 4785074604081154, "label": "knows", "end_id":
281474976710666, "start_id": 281474976710659, "properties": {"years": 4,
"relationship": "enemies"}}::edge, {"id": 281474976710666, "label": "",
"properties": {"age": 6}}::vertex]::path
+ [{"id": 281474976710661, "label": "", "properties": {"age": 4, "name":
"T"}}::vertex, {"id": 4785074604081153, "label": "knows", "end_id":
281474976710666, "start_id": 281474976710661, "properties": {"years": 3,
"relationship": "friends"}}::edge, {"id": 281474976710666, "label": "",
"properties": {"age": 6}}::vertex]::path
(2 rows)
Review Comment:
These rows are reordered due to a plan change, but the underlying Cypher
query has no ORDER BY, so the output order is not guaranteed and can change
across planner/PG versions. To keep the regression stable, consider adding an
ORDER BY in the corresponding regress/sql/cypher_match.sql query (e.g.,
ordering by a stable key) instead of encoding the incidental order in the
expected file.
##########
regress/sql/containment_selectivity.sql:
##########
@@ -0,0 +1,86 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+/*
+ * Regression coverage for issue #2356:
+ * The containment (@>, <@, @>>, <<@) and key-existence (?, ?|, ?&)
+ * operators on agtype must be bound to the lightweight selectivity
+ * helpers contsel / contjoinsel during planning. Earlier PG14+
+ * branches used matchingsel / matchingjoinsel, which caused planning
+ * to invoke agtype_contains() against pg_statistic MCVs and produced
+ * a 30%+ planning-time regression on point queries (severe TPS drop
+ * reported on the PG18 branch).
+ *
+ * This test pins the bindings by querying pg_operator directly. If
+ * someone re-introduces matchingsel here, the test diff is loud and
+ * precise.
+ */
+
+LOAD 'age';
+SET search_path TO ag_catalog;
+
+-- Selectivity helpers for the four containment operators.
+SELECT o.oprname,
+ pg_catalog.format_type(o.oprleft, NULL) AS lhs,
+ pg_catalog.format_type(o.oprright, NULL) AS rhs,
+ o.oprrest::text AS restrict_fn,
+ o.oprjoin::text AS join_fn
+FROM pg_catalog.pg_operator o
+JOIN pg_catalog.pg_namespace n ON n.oid = o.oprnamespace
+WHERE n.nspname = 'ag_catalog'
+ AND o.oprname IN ('@>', '<@', '@>>', '<<@')
+ORDER BY o.oprname, lhs, rhs;
+
+-- Selectivity helpers for all key-existence operator overloads
+-- (right-hand side may be text, text[], or agtype).
+SELECT o.oprname,
+ pg_catalog.format_type(o.oprleft, NULL) AS lhs,
+ pg_catalog.format_type(o.oprright, NULL) AS rhs,
+ o.oprrest::text AS restrict_fn,
+ o.oprjoin::text AS join_fn
+FROM pg_catalog.pg_operator o
+JOIN pg_catalog.pg_namespace n ON n.oid = o.oprnamespace
+WHERE n.nspname = 'ag_catalog'
+ AND o.oprname IN ('?', '?|', '?&')
+ORDER BY o.oprname, lhs, rhs;
+
+-- A single aggregate guard: there must be NO operator in ag_catalog whose
+-- selectivity is still bound to matchingsel / matchingjoinsel. This is the
+-- catch-all that keeps issue #2356 from silently regressing if a future
+-- operator is added.
+SELECT COUNT(*) AS leaked_matchingsel_bindings
+FROM pg_catalog.pg_operator o
+JOIN pg_catalog.pg_namespace n ON n.oid = o.oprnamespace
+WHERE n.nspname = 'ag_catalog'
Review Comment:
The aggregate guard asserts there are *no* operators in ag_catalog bound to
matchingsel/matchingjoinsel, which is broader than the specific
containment/key-existence operators covered by issue #2356. If you want this
test to only pin the fix for those operators, consider scoping the guard to the
10 relevant operator signatures (or their underlying support functions) rather
than enforcing this across all ag_catalog operators.
##########
regress/expected/cypher_vle.out:
##########
@@ -726,8 +726,8 @@ SELECT prepend_node('list01', 'b');
SELECT * FROM show_list_use_vle('list01');
node
-----------------------------------------------------------------------------------
- {"id": 1407374883553282, "label": "node", "properties": {"content":
"b"}}::vertex
{"id": 1407374883553281, "label": "node", "properties": {"content":
"a"}}::vertex
+ {"id": 1407374883553282, "label": "node", "properties": {"content":
"b"}}::vertex
(2 rows)
Review Comment:
The underlying function/query producing this output does not specify an
ORDER BY, so the row order is not guaranteed and can change when planner
choices change (as seen here). Consider adding an explicit ORDER BY in
regress/sql/cypher_vle.sql (within show_list_use_vle's Cypher query or the
outer SELECT) to make the regression output deterministic.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
