Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Match query with operator and, cutoff_frequency and stacked tokens #6573

Merged
merged 1 commit into from Jun 25, 2014
Merged

Match query with operator and, cutoff_frequency and stacked tokens #6573

merged 1 commit into from Jun 25, 2014

Conversation

clintongormley
Copy link

If the match query with cutoff_frequency encounters stacked tokens,
like synonyms in the same position, it returns a boolean query instead
of a common terms query. However, if the original operator was set
to "and", it was ignoring that and resetting the operator to "or".

In fact, if operator is "and" then there is little benefit in using
a common terms query as a must query is already
executed efficiently.

Fixed by 30c8031

@areek areek assigned rmuir and unassigned rmuir Jun 23, 2014
@s1monw
Copy link
Contributor

s1monw commented Jun 24, 2014

LGTM

@s1monw s1monw removed the review label Jun 24, 2014
If the match query with cutoff_frequency encounters stacked tokens,
like synonyms in the same position, it returns a boolean query instead
of a common terms query.  However, if the original operator was set
to "and", it was ignoring that and resetting the operator to "or".

In fact, if operator is "and" then there is little benefit in using
a common terms query as a must query is already
executed efficiently.
@clintongormley clintongormley merged commit 30c8031 into elastic:master Jun 25, 2014
clintongormley added a commit that referenced this pull request Jun 25, 2014
If the match query with cutoff_frequency encounters stacked tokens,
like synonyms in the same position, it returns a boolean query instead
of a common terms query.  However, if the original operator was set
to "and", it was ignoring that and resetting the operator to "or".

In fact, if operator is "and" then there is little benefit in using
a common terms query as a must query is already
executed efficiently.

Closes #6573
@clintongormley clintongormley deleted the match_cutoff_freq branch June 25, 2014 16:02
@clintongormley clintongormley changed the title Match query with operator and, cutoff_frequency and stacked tokens Query DSL: Match query with operator and, cutoff_frequency and stacked tokens Jul 2, 2014
@clintongormley clintongormley changed the title Query DSL: Match query with operator and, cutoff_frequency and stacked tokens Search: Match query with operator and, cutoff_frequency and stacked tokens Jul 9, 2014
@clintongormley clintongormley added the :Search/Search Search-related issues that do not fall into other categories label Jun 7, 2015
@clintongormley clintongormley changed the title Search: Match query with operator and, cutoff_frequency and stacked tokens Match query with operator and, cutoff_frequency and stacked tokens Jun 7, 2015
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
If the match query with cutoff_frequency encounters stacked tokens,
like synonyms in the same position, it returns a boolean query instead
of a common terms query.  However, if the original operator was set
to "and", it was ignoring that and resetting the operator to "or".

In fact, if operator is "and" then there is little benefit in using
a common terms query as a must query is already
executed efficiently.

Closes elastic#6573
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search/Search Search-related issues that do not fall into other categories v1.2.2 v1.3.0 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants