[GitHub] [lucene] MarcusSorealheis commented on issue #12204: ToParentBlockJoinQuery's explain should depend on its ScoreMode

MarcusSorealheis commented on issue #12204: URL: https://github.com/apache/lucene/issues/12204#issuecomment-1477343261 I think both of those options make sense. I think polymorphism would be pretty elegant, but copying the score logic scares me a bit. I'll think about about these and other

[GitHub] [lucene] zacharymorn commented on pull request #12194: [GITHUB-11915] [Discussion Only] Make Lucene smarter about long runs of matches via new API on DISI

zacharymorn commented on PR #12194: URL: https://github.com/apache/lucene/pull/12194#issuecomment-1477253989 > I have some suggestions for moving this PR forward: > > * Enhance CheckIndex to check that peekNextNonMatcthingDocID is correct. > * Enhance AssertingScorer to check that p

[GitHub] [lucene] MarcusSorealheis commented on issue #12209: CPU usage continuously increasing when IMAP SEARCH command coming from user agent

MarcusSorealheis commented on issue #12209: URL: https://github.com/apache/lucene/issues/12209#issuecomment-1477024422 > Lucene: 3.6.2 I want to help you because it sounds like an interesting problem. However, I don't think most in the community can offer much support for a versio

[GitHub] [lucene] MarcusSorealheis closed issue #12166: `pointInPolygon` method in Tesselator is no longer used

MarcusSorealheis closed issue #12166: `pointInPolygon` method in Tesselator is no longer used URL: https://github.com/apache/lucene/issues/12166 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the s

[GitHub] [lucene] rmuir commented on pull request #12207: simplify PrefixQuery to avoid requiring Automaton

rmuir commented on PR #12207: URL: https://github.com/apache/lucene/pull/12207#issuecomment-1476657449 i'm suspicious of the benchmarking, we shouldn't be taking any benchmarks of 10k/1m seriously. only the 10m is reasonably reliable. And I don't see any real improvements there? But

[GitHub] [lucene] jpountz commented on pull request #12194: [GITHUB-11915] [Discussion Only] Make Lucene smarter about long runs of matches via new API on DISI

jpountz commented on PR #12194: URL: https://github.com/apache/lucene/pull/12194#issuecomment-1475794788 I have some suggestions for moving this PR forward: - Enhance CheckIndex to check that peekNextNonMatcthingDocID is correct. - Enhance AssertingScorer to check that peekNextNonMatc

[GitHub] [lucene] jpountz commented on pull request #12194: [GITHUB-11915] [Discussion Only] Make Lucene smarter about long runs of matches via new API on DISI

jpountz commented on PR #12194: URL: https://github.com/apache/lucene/pull/12194#issuecomment-1475781767 > As Lucene does a lot of two phase iterations, and two phase iterator's approximation may provide a superset of the actual matches. If we were to use this API to find and ignore / skip

[GitHub] [lucene] mkhludnev commented on issue #12204: ToParentBlockJoinQuery's explain should depend on its ScoreMode

mkhludnev commented on issue #12204: URL: https://github.com/apache/lucene/issues/12204#issuecomment-1475778915 @MarcusSorealheis, Well.. I don't have an elegant solution in mind, beside of almost fully copying score logic into explain or some crazy hairy polimorphish. Probably, somewhat co