[jira] [Commented] (LUCENE-8675) Divide Segment Search Amongst Multiple Threads
[ https://issues.apache.org/jira/browse/LUCENE-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575251#comment-17575251 ] Adrien Grand commented on LUCENE-8675: -- I wonder if we could avoid paying the cost of Scorer/BulkScorer initialization multiple times by implementing Cloneable on these classes, similarly to how we use cloning on IndexInputs to consume them from multiple threads. It would require implementing Cloneable on a few other classes, e.g. PostingsEnum, and maybe we'd need to set some restrictions to keep this feature reasonable, e.g. it's only legal to clone when the current doc ID is -1. But this could help parallelize collecting a single segment by assigning each clone its own range of doc IDs. A downside of this approach is that it wouldn't help parallelize the initialization of Scorers, but I don't know if there is a way around it. > Divide Segment Search Amongst Multiple Threads > -- > > Key: LUCENE-8675 > URL: https://issues.apache.org/jira/browse/LUCENE-8675 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > Attachments: PhraseHighFreqP50.png, PhraseHighFreqP90.png, > TermHighFreqP50.png, TermHighFreqP90.png > > > Segment search is a single threaded operation today, which can be a > bottleneck for large analytical queries which index a lot of data and have > complex queries which touch multiple segments (imagine a composite query with > range query and filters on top). This ticket is for discussing the idea of > splitting a single segment into multiple threads based on mutually exclusive > document ID ranges. > This will be a two phase effort, the first phase targeting queries returning > all matching documents (collectors not terminating early). The second phase > patch will introduce staged execution and will build on top of this patch. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8675) Divide Segment Search Amongst Multiple Threads
[ https://issues.apache.org/jira/browse/LUCENE-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575323#comment-17575323 ] Michael McCandless commented on LUCENE-8675: bq. I wonder if we could avoid paying the cost of Scorer/BulkScorer initialization multiple times by implementing Cloneable on these classes, similarly to how we use cloning on IndexInputs to consume them from multiple threads. +1 > Divide Segment Search Amongst Multiple Threads > -- > > Key: LUCENE-8675 > URL: https://issues.apache.org/jira/browse/LUCENE-8675 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > Attachments: PhraseHighFreqP50.png, PhraseHighFreqP90.png, > TermHighFreqP50.png, TermHighFreqP90.png > > > Segment search is a single threaded operation today, which can be a > bottleneck for large analytical queries which index a lot of data and have > complex queries which touch multiple segments (imagine a composite query with > range query and filters on top). This ticket is for discussing the idea of > splitting a single segment into multiple threads based on mutually exclusive > document ID ranges. > This will be a two phase effort, the first phase targeting queries returning > all matching documents (collectors not terminating early). The second phase > patch will introduce staged execution and will build on top of this patch. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] gsmiller opened a new pull request, #1058: LUCENE-10207: TermInSetQuery now provides a ScoreSupplier with cost estimation for use in TermInSetQuery
gsmiller opened a new pull request, #1058: URL: https://github.com/apache/lucene/pull/1058 This makes incremental progress against LUCENE-10207, allowing `TermInSetQuery` to provide cost estimation so it might be used in an `IndexOrDocValuesQuery`. -- 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 specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10207) Make TermInSetQuery usable with IndexOrDocValuesQuery
[
https://issues.apache.org/jira/browse/LUCENE-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575402#comment-17575402
]
Greg Miller commented on LUCENE-10207:
--
I'm coming back to this work now as I'm working on another project that would
benefit from the ability to use a {{TermInSetQuery}} within an
{{IndexOrDocValuesQuery}}. Where this work stalled last year was in answering
whether-or-not making {{TermInSetQuery}} extend {{MultiTermQuery}} would have a
negative performance impact, since the term intersection implementation would
differ. The motivation for extending {{MultiTermQuery}} was to make a doc
values-based term-in-set implementation easy (using the existing
{{DocValuesRewriteMethod}}.
I suggest we separate some of these concerns to make progress. The sandbox
module already has {{DocValuesTermsQuery}} that could be paired with
{{TermInSetQuery}} inside of {{IndexOrDocValuesQuery}}. But, we still can't use
{{TermInSetQuery}} in a {{IndexOrDocValuesQuery}} since {{TermInSetQuery}}
doesn't provide a {{ScoreSupplier}} with cost estimation. I propose we address
this first, and not worry about refactoring {{TermInSetQuery}} to extend
{{MultiTermQuery}} at this point. This would be incremental progress that
enable using {{TermInSetQuery}} + {{DocValuesTermsQuery}} in an
{{IndexOrDocValuesQuery}}, while not requiring us to answer the performance
impact of changing {{TermInSetQuery}} to extend {{MultiTermQuery}}.
I've opened a separate PR to make this iterative step:
https://github.com/apache/lucene/pull/1058
> Make TermInSetQuery usable with IndexOrDocValuesQuery
> -
>
> Key: LUCENE-10207
> URL: https://issues.apache.org/jira/browse/LUCENE-10207
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Greg Miller
>Priority: Minor
> Attachments: LUCENE-10207_multitermquery.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IndexOrDocValuesQuery is very useful to pick the right execution mode for a
> query depending on other bits of the query tree.
> We would like to be able to use it to optimize execution of TermInSetQuery.
> However IndexOrDocValuesQuery only works well if the "index" query can give
> an estimation of the cost of the query without doing anything expensive (like
> looking up all terms of the TermInSetQuery in the terms dict). Maybe we could
> implement it for primary keys (terms.size() == sumDocFreq) by returning the
> number of terms of the query? Another idea is to multiply the number of terms
> by the average postings length, though this could be dangerous if the field
> has a zipfian distribution and some terms have a much higher doc frequency
> than the average.
> [~romseygeek] and I were discussing this a few weeks ago, and more recently
> [~mikemccand] and [~gsmiller] again independently. So it looks like there is
> interest in this. Here is an email thread where this was recently discussed:
> https://lists.apache.org/thread.html/re3b20a486c9a4e66b2ca4a2646e2d3be48535a90cdd95911a8445183%40%3Cdev.lucene.apache.org%3E.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10674) BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength of bitsets
Jack Mazanec created LUCENE-10674: - Summary: BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength of bitsets Key: LUCENE-10674 URL: https://issues.apache.org/jira/browse/LUCENE-10674 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 9.3, 9.2, 9.1, 9.0 Reporter: Jack Mazanec In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285][,|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285],] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()](https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263), the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10674) BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength of bitsets
[ https://issues.apache.org/jira/browse/LUCENE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Mazanec updated LUCENE-10674: -- Description: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()]([https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]), the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 was: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285][,|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285],] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()](https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263), the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 > BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength > of bitsets > -- > > Key: LUCENE-10674 > URL: https://issues.apache.org/jira/browse/LUCENE-10674 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 9.0, 9.1, 9.2, 9.3 >Reporter: Jack Mazanec >Priority: Minor > > In > [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] > if the lead doc is greater than or equal to the length of any of the > BitSets, NO_MORE_DOCS is returned. > > On subsequent calls to > [BitSetConjunctionDISI.docId()]([https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]), > the lead's docID which is not exhausted will be returned. > > I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before > returning NO_MORE_DOCS in doNext. > > Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10674) BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength of bitsets
[ https://issues.apache.org/jira/browse/LUCENE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Mazanec updated LUCENE-10674: -- Description: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()|[https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]], the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 was: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()]([https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]), the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 > BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength > of bitsets > -- > > Key: LUCENE-10674 > URL: https://issues.apache.org/jira/browse/LUCENE-10674 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 9.0, 9.1, 9.2, 9.3 >Reporter: Jack Mazanec >Priority: Minor > > In > [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] > if the lead doc is greater than or equal to the length of any of the > BitSets, NO_MORE_DOCS is returned. On subsequent calls to > [BitSetConjunctionDISI.docId()|[https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]], > the lead's docID which is not exhausted will be returned. I think this could > be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS > in doNext. > > Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10674) BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength of bitsets
[ https://issues.apache.org/jira/browse/LUCENE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Mazanec updated LUCENE-10674: -- Description: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId(),|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263] the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 was: In [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] if the lead doc is greater than or equal to the length of any of the BitSets, NO_MORE_DOCS is returned. On subsequent calls to [BitSetConjunctionDISI.docId()|[https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263]], the lead's docID which is not exhausted will be returned. I think this could be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS in doNext. Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 > BitSetConjunctionDISI iterators fall out of sync when lead doc >= minlength > of bitsets > -- > > Key: LUCENE-10674 > URL: https://issues.apache.org/jira/browse/LUCENE-10674 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 9.0, 9.1, 9.2, 9.3 >Reporter: Jack Mazanec >Priority: Minor > > In > [BitSetConjunctionDISI.doNext()|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L283-L285] > if the lead doc is greater than or equal to the length of any of the > BitSets, NO_MORE_DOCS is returned. On subsequent calls to > [BitSetConjunctionDISI.docId(),|https://github.com/apache/lucene/blob/releases/lucene/9.3.0/lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java#L263] > the lead's docID which is not exhausted will be returned. I think this could > be fixed by calling lead.advance(NO_MORE_DOCS) before returning NO_MORE_DOCS > in doNext. > > Related issue: https://issues.apache.org/jira/browse/LUCENE-9541 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mikemccand commented on a diff in pull request #1016: LUCENE-10646: Add some comment on LevenshteinAutomata
mikemccand commented on code in PR #1016:
URL: https://github.com/apache/lucene/pull/1016#discussion_r938296312
##
lucene/core/src/java/org/apache/lucene/util/automaton/Automaton.java:
##
@@ -576,8 +573,6 @@ public void writeDot(String fileName) {
* visualizing the automaton.
*/
public String toDot() {
-// TODO: breadth first search so we can get layered output...
-
Review Comment:
Yay! Thanks for trying this :)
--
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 specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mikemccand commented on pull request #1016: LUCENE-10646: Add some comment on LevenshteinAutomata
mikemccand commented on PR #1016: URL: https://github.com/apache/lucene/pull/1016#issuecomment-1205835328 Did you try `toDot()` again and confirm the weird as-of-yet unexplained dead states are pruned? -- 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 specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10570) Monitor Presearcher to reject registration of "ANYTOKEN" queries
[
https://issues.apache.org/jira/browse/LUCENE-10570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575492#comment-17575492
]
Chris M. Hostetter commented on LUCENE-10570:
-
FWIW: I've found that in practice, this kind of Presearcher wrapper is a good
"last resort" safety net to prevent these queries from making into the Monitor
– but because of how the Monitor API works to add+commit an entire batch all at
once, it's really only efficient to register large batches of {{MonitorQuery}}
, but if the Presearcher throws an exception, the entire batch fails.
What I've wound up doing is using this kind of Presearcher wrapper in my
Monitor, but also pre-processing the queries (and redundently running them
through the Presearcher individually before assembling my batches) to check
them in advance.
> Monitor Presearcher to reject registration of "ANYTOKEN" queries
> -
>
> Key: LUCENE-10570
> URL: https://issues.apache.org/jira/browse/LUCENE-10570
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/monitor
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: LUCENE-10570.patch
>
>
> I'm starting to do some work with Monitor, and one of the things i realized I
> was going to want is an easy way to detect Queries that result in
> {{ANYTOKEN}} style QueryIndex documents – requiring a "forward search" test
> against every future {{match(Document)}} call.
> The simplest solution I could come up with is a Presearcher "wrapper" –
> something that might be generally useful for other users – but I'm certainly
> open to other approaches.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10675) MonitorConfiguration should support disabling scheduled purgeCache
Chris M. Hostetter created LUCENE-10675:
---
Summary: MonitorConfiguration should support disabling scheduled
purgeCache
Key: LUCENE-10675
URL: https://issues.apache.org/jira/browse/LUCENE-10675
Project: Lucene - Core
Issue Type: Improvement
Components: modules/monitor
Reporter: Chris M. Hostetter
Monitors (using WritableQueryIndex) automatically create a private
ScheduledExecutor using a hardcoded ThreadFactory to schedule a periodic call
to the {{purgeCache()}} method.
The frequency of this periodic schedule can be adjusted via
MonitorConifguration – but it can't be disabled.
This seems odd because:
* {{purgeCache()}} is a public method that applications using a Monitor can
invoke themselves (possible via their own ScheduledExecutor)
* In a lot of usecases there's no need for periodicly calling this method –
it's enough to call exactly once after {{{}register(){}}}-ing or
{{{}deleteById(){}}}-ing one or more batches of {{MonitorQuery}} objects.
there is zero reason to call it again unless/untill something changes.
I propose we tweak the MonitorConfiguration API spec, and the use of the
configuration in the code, such that if the configured purgeFrequency is a
negative number, The {{purgeExecutor}} remains null (and no Executor is ever
created)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] tang-hi commented on pull request #1016: LUCENE-10646: Add some comment on LevenshteinAutomata
tang-hi commented on PR #1016: URL: https://github.com/apache/lucene/pull/1016#issuecomment-1205985454 > Did you try `toDot()` again and confirm the weird as-of-yet unexplained dead states are pruned? Yes! It now looks like below (input -> "abcd" ,trans -> true, distance -> 1)  -- 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 specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-jira-archive] mocobeta commented on issue #104: Should we regenerate another full export?
mocobeta commented on issue #104: URL: https://github.com/apache/lucene-jira-archive/issues/104#issuecomment-1206028981 All issues were successfully imported to https://github.com/mocobeta/forks-migration-test-2/issues with the latest main. Issue link remapping is ongoing. -- 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 specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
