Ignacio Vera created LUCENE-10288:
-------------------------------------
Summary: Are 1-dimensional kd trees in pre-86 indices always
unbalanced trees?
Key: LUCENE-10288
URL: https://issues.apache.org/jira/browse/LUCENE-10288
Project: Lucene - Core
Issue Type: Bug
Reporter: Ignacio Vera
I am looking into a set error, it can be reproduced with the following command
in brach 9x:
{code}
./gradlew :lucene:backward-codecs:test --tests
"org.apache.lucene.backward_codecs.lucene60.TestLucene60PointsFormat.testOneDimTwoValues"
-Dtests.seed=A70882387D2AAFC2 -Dtests.multiplier=3
{code}
The actual error looks looks like:
{code:java}
org.apache.lucene.backward_codecs.lucene60.TestLucene60PointsFormat > test
suite's output saved to
/Users/ivera/projects/lucene_prod/lucene/backward-codecs/build/test-results/test/outputs/OUTPUT-org.apache.lucene.backward_codecs.lucene60.TestLucene60PointsFormat.txt,
copied below:
> java.lang.AssertionError: expected:<1137> but was:<1138>
> at
__randomizedtesting.SeedInfo.seed([A70882387D2AAFC2:1B737C7FDE6454F3]:0)
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
{code}
For Lucene created with this codec we assume that for 1D cases, the kd-trees
are unbalance but for the ND case we assume that they are always fully balance.
This is true for the generic case but this failure might show that it might not
always the case.
During this test a merging is going on, but during the merge we Havel the
following code:
{code:java}
for (PointsReader reader : mergeState.pointsReaders) {
if (reader instanceof Lucene60PointsReader == false) {
// We can only bulk merge when all to-be-merged segments use our format:
super.merge(mergeState);
return;
}
} {code}
So we only bulk merge segments that use `Lucene60PointsReader`. Not that if we
do not bulk merge a 1D index then it will be created as a fully balanced tree!
In this case the test is wrapping the readers with the
{{SlowCodecReaderWrapper}} and therefore tricking our logic.
But I am wondering if this the case for Index sorting where our readers might
be wrapped with the {{{}SortingCodecReader{}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
