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

Fix wrong error upper bound when performing incremental reductions #43874

Merged
merged 10 commits into from
Jul 22, 2021
Merged

Fix wrong error upper bound when performing incremental reductions #43874

merged 10 commits into from
Jul 22, 2021

Conversation

Hohol
Copy link
Contributor

@Hohol Hohol commented Jul 2, 2019

When performing incremental reductions, 0 value of docCountError may mean that the error was not previously calculated, or that the error was indeed previously calculated and its value was 0. We end up rejecting true values set to 0 this way.
This may lead to wrong upper bound of error in result.
To fix it, this PR makes docCountError nullable. null values mean that error was not calculated yet.

Fixes #40005

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo

@Hohol
Copy link
Contributor Author

Hohol commented Jul 5, 2019

@jpountz, @jimczi, can I get some reviewers, please?

@polyfractal
Copy link
Contributor

Apologies for the delay on a review, lots of folks have been in/out due to summer holidays :)

I'll take a look at it early this week, and I've also requested a review from @javanna when he gets back from holiday (also early this week). Thanks for the PR @Hohol!

@colings86 colings86 added v7.5.0 and removed v7.4.0 labels Aug 30, 2019
@jimczi jimczi added v7.6.0 and removed v7.5.0 labels Nov 12, 2019
@Hohol
Copy link
Contributor Author

Hohol commented Nov 15, 2019

I've updated the PR. Can we finish this?
Is the issue still relevant at all?

@Hohol
Copy link
Contributor Author

Hohol commented Nov 15, 2019

Oops, looks like diff is unreadable now.

@Hohol
Copy link
Contributor Author

Hohol commented Nov 15, 2019

Rebased.

@Hohol
Copy link
Contributor Author

Hohol commented Nov 21, 2019

@polyfractal, @javanna, @colings86, can someone answer, please?

@polyfractal polyfractal added v7.7.0 and removed v7.6.0 labels Jan 15, 2020
@bpintea bpintea added v7.8.0 and removed v7.7.0 labels Mar 25, 2020
@rjernst rjernst added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label May 4, 2020
Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

I think this is right. I'm really sorry we lost track of this one. It seems like a good change. I left a small question, but I think its right.

@imotov thought I knew this code fairly well. I'm not 100% confident in my ability to reason about it all in my head but with the test change and his confidence I'm happy with the change.

@@ -51,7 +52,14 @@ protected InternalMappedTerms(String name, BucketOrder reduceOrder, BucketOrder
*/
protected InternalMappedTerms(StreamInput in, Bucket.Reader<B> bucketReader) throws IOException {
super(in);
docCountError = in.readZLong();
if (in.getVersion().onOrAfter(Version.V_8_0_0)) { // todo fix after backport
docCountError = in.readOptionalLong();
Copy link
Member

Choose a reason for hiding this comment

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

Should this stay a zlong?

Copy link
Contributor

Choose a reason for hiding this comment

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

@nik9000 why was it a zlong in the first place? Can errors be negative?

@nik9000
Copy link
Member

nik9000 commented Jul 1, 2021 via email

@imotov
Copy link
Contributor

imotov commented Jul 6, 2021

@elasticmachine update branch

@imotov
Copy link
Contributor

imotov commented Jul 6, 2021

@elasticmachine test this please

@not-napoleon not-napoleon self-requested a review July 13, 2021 17:56
Copy link
Member

@not-napoleon not-napoleon left a comment

Choose a reason for hiding this comment

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

I've read this twice now, and I think it's okay. Very tricky.

@@ -1014,4 +1030,17 @@ public void testFixedDocs() throws Exception {
assertThat(bucket.getDocCountError(), equalTo(29L));
}

public void testIncrementalReductionBug() {
Copy link
Member

Choose a reason for hiding this comment

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

I'm nitpicking, but it'd be good to explain exactly what this is testing, or at least link to the issue. In a year, we'll have no idea what it's supposed to do.

@imotov
Copy link
Contributor

imotov commented Jul 21, 2021

@elasticmachine update branch

@imotov
Copy link
Contributor

imotov commented Jul 21, 2021

@elasticmachine test this please

@imotov
Copy link
Contributor

imotov commented Jul 21, 2021

@elasticmachine run elasticsearch-ci/part-1

@imotov imotov merged commit 1db17ad into elastic:master Jul 22, 2021
@Hohol Hohol deleted the nullable-doc-count-error branch July 23, 2021 08:21
ywangd pushed a commit to ywangd/elasticsearch that referenced this pull request Jul 30, 2021
…lastic#43874)

When performing incremental reductions, 0 value of docCountError may mean that 
the error was not previously calculated, or that the error was indeed previously 
calculated and its value was 0. We end up rejecting true values set to 0 this 
way. This may lead to wrong upper bound of error in result. To fix it, this PR 
makes docCountError nullable. null values mean that error was not calculated 
yet.

Fixes elastic#40005

Co-authored-by: Igor Motov <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
imotov added a commit to imotov/elasticsearch that referenced this pull request Aug 11, 2021
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes
in elastic#43874. The first error was introduced in the original PR, where unknown doc
count errors were initialized equal to 0, the second was introduced during in
order to fix the first one by ignoring these 0s, which essentially disabled the
original fix.

Fixes elastic#75667
imotov added a commit that referenced this pull request Aug 12, 2021
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes
in #43874. The first error was introduced in the original PR, where unknown doc
count errors were initialized equal to 0, the second was introduced during in
order to fix the first one by ignoring these 0s, which essentially disabled the
original fix.

Fixes #75667
imotov added a commit to imotov/elasticsearch that referenced this pull request Aug 12, 2021
…lastic#43874)

When performing incremental reductions, 0 value of docCountError may mean that
the error was not previously calculated, or that the error was indeed previously
calculated and its value was 0. We end up rejecting true values set to 0 this
way. This may lead to wrong upper bound of error in result. To fix it, this PR
makes docCountError nullable. null values mean that error was not calculated
yet.

Fixes elastic#40005

Co-authored-by: Igor Motov <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
imotov added a commit to imotov/elasticsearch that referenced this pull request Aug 12, 2021
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes
in elastic#43874. The first error was introduced in the original PR, where unknown doc
count errors were initialized equal to 0, the second was introduced during in
order to fix the first one by ignoring these 0s, which essentially disabled the
original fix.

Fixes elastic#75667
imotov added a commit that referenced this pull request Aug 16, 2021
…ons (#43874) (#76475)

When performing incremental reductions, 0 value of docCountError may mean that
the error was not previously calculated, or that the error was indeed previously
calculated and its value was 0. We end up rejecting true values set to 0 this
way. This may lead to wrong upper bound of error in result. To fix it, this PR
makes docCountError nullable. null values mean that error was not calculated
yet.

Fixes #40005, #75667

Co-authored-by: Nikita Glashenko <[email protected]>
@javanna
Copy link
Member

javanna commented Apr 1, 2022

I was expecting this to address an issue I found in CCSDuelIT, but that does not seem to be the case. See #85538 . We still have an awaitsfix and a failure when we try and remove it. Could you help with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Aggregations Aggregations >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v7.15.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error upper bound may be wrong when performing incremental reductions