You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can potentially support this by introducing a filter parameter, which takes the same parameter as q, but pass as the filtered query. It can be combined with q as the query part as well.
The text was updated successfully, but these errors were encountered:
alternatively, we can reuse q parameter, but use an "as_filter" flag to indicate if the query should be queried as a filtered query or not. In this case, no combination of q and filter, can only do either one.
We can discuss to see which is preferred, or even support both.
Using the filter context may improve performance if it gets cached by Elasticsearch (which is, in the end, a maybe). Other than that, is there a specific reason that we would want to use the filter context instead of the query context?
In some cases we are already using both: for example in interval queries in MyVariant
When the order of the hits and _score values do not matter, the filtered query can be preferred. There are several ways to make such queries:
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-bool-query.html#score-bool-filter
We can potentially support this by introducing a
filter
parameter, which takes the same parameter asq
, but pass as the filtered query. It can be combined withq
as the query part as well.The text was updated successfully, but these errors were encountered: