Avoid PIT context exhaustion by pruning indices that cannot match

common/src/main/java/org/opensearch/sql/common/setting/Settings.java

@@ -52,6 +52,7 @@ public enum Key {
     /** Common Settings for SQL and PPL. */
     QUERY_MEMORY_LIMIT("plugins.query.memory_limit"),
     QUERY_SIZE_LIMIT("plugins.query.size_limit"),
+    QUERY_PRUNING_ENABLED("plugins.query.pruning.enabled"),
     MAX_EXPRESSION_DEPTH("plugins.query.max_expression_depth"),
     DESERIALIZATION_MAX_DEPTH("plugins.query.deserialization.max_depth"),
     DESERIALIZATION_MAX_REFS("plugins.query.deserialization.max_refs"),

docs/user/admin/settings.rst

@@ -204,6 +204,55 @@ Result set::
       }
     }
 
+plugins.query.pruning.enabled (Experimental)
+============================================
+
+Version
+-------
+3.9
+
+Description
+-----------
+
+Prunes a wildcard index expression down to the concrete indices that can hold data in the query's ``@timestamp`` range, so fewer indices and shards are touched. The primary use currently is to avoid exhausting the open point-in-time (PIT) context limit when a query would otherwise open a reader context over many indices.
+
+Pruning only applies to a wildcard expression whose query filters on a ``@timestamp`` range, and never to one that names a remote cluster; anything else is left untouched, and any failure while probing the cluster falls back to querying the full expression. Weigh these limitations before enabling it:
+
+1. An index whose shards are all unavailable is pruned rather than reported, because ``_field_caps`` does not surface per-index failures. Such a query returns fewer rows instead of an error.
+2. Pruning fixes the list of index names, so an index created or deleted between pruning and PIT creation, by a rollover or retention policy for instance, is missed or fails the query. The interval between the two is short, so this is unlikely in practice.
+3. An expression that matches an alias or a data stream is never pruned, because a filtered alias contributes a filter and routing that are resolved from the expression itself and so would be silently dropped.
+4. Pruning probes the cluster with the ``indices:admin/resolve/index`` and ``indices:data/read/field_caps`` actions, so a principal lacking either permission falls back to querying the full expression.
+
+Pruning is also skipped whenever it would not reduce the read: when no index is excluded, and when the list of matching indices is longer than an internal cap (50 indices after pruning). Both cases query the original wildcard expression, which reads the same indices when nothing was excluded and more when the cap declined. Here is an example::
+
+	>> curl -H 'Content-Type: application/json' -X PUT localhost:9200/_plugins/_query/settings -d '{
+	  "transient" : {
+	    "plugins.query.pruning.enabled" : true
+	  }
+	}'
+
+Result set::
+
+    {
+      "acknowledged" : true,
+      "persistent" : { },
+      "transient" : {
+        "plugins" : {
+          "query" : {
+            "pruning" : {
+              "enabled" : "true"
+            }
+          }
+        }
+      }
+    }
+
+Settings:
+
+1. The default value is false.
+2. This setting is node scope.
+3. This setting can be updated dynamically.
+
 plugins.query.max_expression_depth
 ==================================