mohamedniyaz1996 opened a new issue, #11902:
URL: https://github.com/apache/lucene/issues/11902
### Description
I came across this python library
[weighted-levenshtein](https://pypi.org/project/weighted-levenshtein/) which
has a way to specify different costs for insertion, deletion,
jpountz commented on PR #11875:
URL: https://github.com/apache/lucene/pull/11875#issuecomment-1305387673
Historically configuring timeouts on searches has been too complicated:
users had to wrap their collector with a `TimeLimitingCollector` and to wrap
their readers with an `ExitableDirect
jpountz opened a new pull request, #11903:
URL: https://github.com/apache/lucene/pull/11903
Since increasing the number of hits retrieved in nightly benchmarks from 10
to 100, the performance of sorting documents by title dropped back to the level
it had before introducing dynamic pruning.
LuXugang merged PR #11884:
URL: https://github.com/apache/lucene/pull/11884
--
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.ap
jpountz commented on PR #11895:
URL: https://github.com/apache/lucene/pull/11895#issuecomment-1305558470
This makes me think that we could also enhance this logic to count queries
that have a mix of `SHOULD` and `MUST_NOT` clauses, in case this is something
you are interested in looking int
donnerpeter opened a new pull request, #11904:
URL: https://github.com/apache/lucene/pull/11904
Various minor optimizations to reduce allocations and unnecessary checks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use t
dweiss commented on code in PR #11904:
URL: https://github.com/apache/lucene/pull/11904#discussion_r1015435007
##
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/AffixCondition.java:
##
@@ -31,8 +31,30 @@
*/
interface AffixCondition {
String ALWAYS_TRUE
donnerpeter commented on code in PR #11904:
URL: https://github.com/apache/lucene/pull/11904#discussion_r1015510285
##
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/AffixCondition.java:
##
@@ -31,8 +31,30 @@
*/
interface AffixCondition {
String ALWAYS
jpountz commented on PR #11860:
URL: https://github.com/apache/lucene/pull/11860#issuecomment-1305835975
I guess that encoding each block with a different number of bits per value
would mostly help if node IDs are somewhat clustered so that the set of
neighbors to a given node would be clos
mikemccand commented on issue #11885:
URL: https://github.com/apache/lucene/issues/11885#issuecomment-1306025198
I'm not sure these classes should be made public? What is the use-case
where this would help?
But big +1 to somehow un-fork them! It's crazy such a scary functionality
i
donnerpeter merged PR #11904:
URL: https://github.com/apache/lucene/pull/11904
--
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
zhaih commented on issue #11885:
URL: https://github.com/apache/lucene/issues/11885#issuecomment-1306203835
@mikemccand Like when we want to do a segment replication (indexer sends new
segments to searcher instead of searcher consuming live updates) but decided
not to use `nrt` module. Then
benwtrent opened a new pull request, #11905:
URL: https://github.com/apache/lucene/pull/11905
This bug has been around since 9.1. It relates directly to the number of
nodes that are contained in the level 0 of the HNSW graph. Since level 0
contains all the nodes, this implies the following:
msokolov commented on PR #11852:
URL: https://github.com/apache/lucene/pull/11852#issuecomment-1306374073
I found this simple thing useful without all that, but nobody else
seems to like the idea - it's fine, I won't push it
On Sun, Nov 6, 2022 at 7:37 AM Tomoko Uchida ***@***.***>
rmuir commented on PR #11905:
URL: https://github.com/apache/lucene/pull/11905#issuecomment-1306601477
Not good: thanks for splitting this out from your other PR! wonder if we can
start cooking up something similar to #11867 ? Looks like we need more vectors
but they can have less dimension
rmuir opened a new pull request, #11906:
URL: https://github.com/apache/lucene/pull/11906
Goal is to reproduce #11905
Basically I adapted the test from #11867 as a start, tweaked the indexing
and merging to try to get it running reasonably, since it needs to make single
segment of 16
rmuir commented on PR #11905:
URL: https://github.com/apache/lucene/pull/11905#issuecomment-1306713558
ok i tried to make a stab at a test in that draft PR, but its still pretty
slow so I'm gonna leave it running. we have to start building up tests for
these cases because this seems like de
17 matches
Mail list logo
