Support empty tags for all WHERE equality operations #6283
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@pauldix here's the change we talked about with regards to empty tags. I'm not sure if we're ok with the lack of indexing for empty tags as I don't really know the use case. The performance change shouldn't affect any existing behavior and should actually make |
If a point had no tags at all and was asked for the subset of tags with at least one key, it would return a new set of tags that was completely empty. In contrast, if the point had any tags at all, it would return a set of tags with the tag value being an empty string. This lead to a point with no tags being treated differently than a point with at least one tag. Fixing this so the tag value will always be an empty string for consistency. A missing tag should always be empty.
A missing tag on a point was sometimes treated as `""` and sometimes treated as a separate `null` entity. This change modifies the equality operations to always treat a missing tag as an empty string. Empty tags are *not* indexed and do not have the same performance as a tag that exists. Fixes #3773.
jsternberg
force-pushed
the
js-3773-treat-tags-as-empty-string
branch
from
7db5691
to
c8e23ec
Compare
|
👍 other than the test failures |
jsternberg
force-pushed
the
js-3773-treat-tags-as-empty-string
branch
from
c8e23ec
to
815c49a
Compare
jsternberg
added a commit
that referenced
this pull request
Aug 31, 2016
The behavior for querying tag values with an empty string was originally fixed in #6283, but it also added a performance problem when the cardinality of the tag was high. Since a call to `Union()` or `Reject()` would happen for every series key and it would be called N times for N cardinality, the comparisons against a blank string were unnecessarily slow with large memory allocations. This optimizes these queries so it doesn't use those methods anymore. Those methods are still useful and used when combining AND and OR clauses, but they aren't useful when finding the series ids for a single clause. These methods were unnecessary anyway because the series ids for the tags were unique anyway and didn't have to be merged as a set.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A missing tag on a point was sometimes treated as
""and sometimestreated as a separate
nullentity. This change modifies the equalityoperations to always treat a missing tag as an empty string.
Empty tags are not indexed and do not have the same performance as a tag
that exists.
Also fixes the subset method on tags to behave consistently with empty tags.
Fixes #3773.