Skip to content

Conversation

@carlosdelest
Copy link
Member

Until #115311 allows filters to be pushed down past STATS .. BY, MATCH can't work after STATS.

STATS produces either a single column that is the result of a computation done in the compute engine, or the additional grouping column specified via BY.

This PR provides a better error message in the meanwhile. We can revert this once #115311 is fixed.

@carlosdelest carlosdelest added Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) :Analytics/ES|QL AKA ESQL Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch v8.17.0 >non-issue labels Nov 12, 2024
@carlosdelest carlosdelest marked this pull request as ready for review November 12, 2024 18:39
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytical-engine (Team:Analytics)

@elasticsearchmachine elasticsearchmachine removed the Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch label Nov 12, 2024
Copy link
Contributor

@ioanatia ioanatia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me - I left a suggestion

condition,
Match.class,
lp -> (lp instanceof Limit == false),
lp -> (lp instanceof Limit == false) && (lp instanceof Aggregate == false),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me - but in these types of situations I prefer to have an "allow list" of commands that can be used before match, rather than check for the ones that cannot be used.
This is what we do for qstr and IMO it's a bit safer, because we do not have to worry when we introduce a new command that we need to immediately update this check here. Worst case when we add a new command we have a limitation in place that we can lift any time.
The other way around, where we have a "deny" list like we do now, when we add a new command, the worst case is that the ES|QL query fails in a way we did not predict.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. As this is temporary until #115311 is fixed, I can revisit the implementation when we change this again.

@carlosdelest carlosdelest added the auto-backport Automatically create backport pull requests when merged label Nov 14, 2024
@carlosdelest carlosdelest merged commit e2e8a46 into elastic:main Nov 14, 2024
15 of 16 checks passed
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

The backport operation could not be completed due to the following error:

An unexpected error occurred when attempting to backport this PR.

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 116642

@carlosdelest
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
8.x

Questions ?

Please refer to the Backport tool documentation

elasticsearchmachine pushed a commit that referenced this pull request Nov 14, 2024
@ChrisHegarty
Copy link
Contributor

I assume that this will resolve #115353, right?

@carlosdelest
Copy link
Member Author

I assume that this will resolve #115353, right?

@ChrisHegarty correct, thanks for the catch! Closed #115353

alexey-ivanov-es pushed a commit to alexey-ivanov-es/elasticsearch that referenced this pull request Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Analytics/ES|QL AKA ESQL auto-backport Automatically create backport pull requests when merged backport pending >non-issue Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.17.0 v9.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants