[Enhancement] Honor search.allow_expensive_queries when planning a script pushdown

Abierto
#5,837 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@RyanL1997 ya está trabajando en esto.

Desde el 19/10/2026.

  • #5896 de @RyanL1997 — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
database

Línea de trabajo

Trace the engine-wide script pushdown paths and check how the plugin reads search settings during planning; the issue names no source files or tests. Use the provided text-field reproduction with search.allow_expensive_queries=false as the first check, then cover the binary and flat_object cases mentioned in the issue. Done means script pushdowns are not emitted when the setting is false, or the rejection clearly identifies the setting and responsible query part.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement performance
What is wrong

A filter PPL cannot express as a DSL query is planned as a script query. OpenSearch already lets an operator refuse those with search.allow_expensive_queries (default true), but the plugin never consults it. When it is false the shard rejects the script and the user gets an error that names neither the setting nor the part of the query responsible:

java.sql.SQLException: exception while executing query: Failed to fetch data from the index:
the background task failed or interrupted.
  Inner error: Failed to execute phase [query], all shards failed; shardFailures
  { ... QueryShardException[failed to create query: [script] queries cannot be executed
  when 'search.allow_expensive_queries' is set to false.] }

A filter the index can answer succeeds in the same state, so the gate already discriminates correctly at the DSL level — the plugin just does not handle the rejection. allow_expensive_queries appears nowhere in the plugin.

Reproduce

A stock mapping: a text field with no keyword sub-field, so equality cannot become a term.

PUT /txtonly
{"settings":{"number_of_shards":1},
 "mappings":{"properties":{"id":{"type":"keyword"},"msg":{"type":"text"}}}}

POST /txtonly/_doc/1?refresh=true
{"id":"a","msg":"hello world"}

PUT /_cluster/settings
{"transient":{"search.allow_expensive_queries":false}}
POST /_plugins/_ppl   {"query": "source=txtonly | where msg = 'hello world' | fields id"}
query with the setting true with it false
where msg = 'hello world' the row the error above
a filter the index can answer (where id = 'a') the row the row

Both engines reach it: the script pushdown is not Calcite-specific.

What it should do

Either of these; the first is preferable because the answer stays correct.

  1. Plan around it. When the setting is false, do not emit a script pushdown — leave the predicate to the coordinator, which is what the engine already does for every other predicate it cannot push down. Slower, still correct.
  2. Refuse clearly. Report that the query needs a script, name the setting, and say which part of the query caused it.
Scope

Engine-wide rather than specific to one field type: every script pushdown path is affected — a text field without a keyword sub-field as above, a binary field (#5757), and a field type with no doc values at all, such as the flat_object leaves added in #5830, where it was found.

Lenguaje dominante
Java
Estrellas
175
Forks
233
Merge medio
3 d 36 min
PR fusionados (30 d)
41

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opensearch-project/sql

Todos los issues de opensearch-project/sql

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.