Lucene: Status=Open

[Save this search]

Author relation

Updated ago

Comment count

Reaction count

Review Requested

User

Last comment user

Type

Filters: Status (Open), Issue type, Author relation, Created, Updated, Updated ago, Comment count, Reaction count, Review Requested, Mentioned, Reviewed, Commented, User, Last comment user, Draft, Component, Type, Labels, Commits?, Reporter, Assignee

#15709 PR: Disable skipper-based term competitive iterators if they are not effective

2.6 hours ago 2 comments 0 votes 0 watches benwtrent, github-actions[bot], romseygeek

Skipper-based competitive iterators for term sorts are only useful if the field being sorted on has ... For cases where these competitive iterators are not helping, we detect that no skipping is actually ... Closes #15707

benwtrent 2.6 hours ago:	I don't really know about iterators enough to give a strong review. It makes sense for it to be adaptive.
benwtrent 2.6 hours ago:	could you indicate that this is only used in testing?

#15707: Significant performance impact with new TermOrdValComparator.SkipperBasedCompetitiveState

8.3 hours ago 2 comments 0 votes 0 watches benwtrent, romseygeek

Description During the 10.4 release process, we noticed a 100-300x slowdown on a benchmark that ... The query is rather innocuous, its an attempt to sort the result by a SORTED SET field while ... The index is sorted by both fields, but also by multiple others.

romseygeek 8.3 hours ago:	I think the issue here is per-document overhead when the skipper-based competitive iterators can't ... We already have some adaptive backoff in NumericComparators for this situation, and I've opened a ... The test that @benwtrent has added above will pass with my PR, although I opted not to include it ...
benwtrent 3 days ago:	OK, I have a test that repeats the failure, I am not 100% sure if it fully represents our use-case. ... Our test uses a compound field as the index sort. This sorting by many various fields might be construed as not really sorting effectively by a ...

#15700 PR: Fix Tessellation error for holes that share the same leftmost vertex with an outer ring vertex

8.7 hours ago 1 comments 0 votes 0 watches github-actions[bot], iverase, roblburris

Description Apologies in advance if this is garbage, but I had Claude make an attempt at fixing ... If multiple holes share the same leftmost vertex, the ring accumulates multiple copies of that ... The angle-based getSharedInsideVertex tiebreaker could select the wrong copy when merging ...

iverase 8.7 hours ago:

I did something similar with similar result. I checked the new code with a set of 400 million polygons and it passed. LGTM I don't know if we can squeeze this change to 10.4, I will try.

#15708 PR: Add optional query bit size hint to KnnSearchStrategy.Hnsw

1.4 days ago 1 comments 0 votes 0 watches arup-chauhan, benwtrent, github-actions[bot]

This PR introduces an optional query bit-size hint for KnnSearchStrategy.Hnsw as a first ... I intentionally limited the scope to search-strategy API plumbing and tests to keep risk low. Default behavior remains unchanged: the new hint is metadata-only in this PR and does not alter ...

arup-chauhan 1.5 days ago:

Hey @benwtrent Implemented the first incremental step by adding an optional queryBitSizeHint to ... I’ve preserved backward compatibility, forwarded the hint through Patience / seeded wrapping paths, ... This PR intentionally does not change scoring behavior.

#15620 PR: Add Temporal Merge Policy for time-series data

1.9 days ago 39 comments 0 votes 0 watches benwtrent, churromorales, github-actions[bot], msfroh, shubhamsrkdev

Description This PR introduces TemporalMergePolicy, a new merge policy designed for time-series ... The policy groups segments into time windows and merges segments within the same window, but never ... This preserves temporal locality and improves query performance for time-range queries. relates to ...

churromorales 1.9 days ago:	just a defensive check, its really if compactionRatio == 1.0d, I can do that as well.
churromorales 3 days ago:	@msfroh honeslty I felt if you had less than 5% deletes than this works just fine, but we could do ... I am totally fine with either approach, I will defer to you guys here.

#15659 PR: Avoid unnecessary DisjunctionMaxBulkScorer overhead

2 days ago 11 comments 0 votes 0 watches benwtrent, github-actions[bot], jpountz, shimpeko, uschindler

This change inspects clause bulk scorers up front and only uses DisjunctionMaxBulkScorer if at ... Otherwise, we fall back to the scorer-based path. c88f9334e5c99abbeb4f233f9606873e5037c118 made DisjunctionMaxQuery use DisjunctionMaxBulkScorer when ...

shimpeko 2.1 days ago:	@jpountz I’ve dropped the idea of switching from DisjunctionMaxBulkScorer to DisjunctionMaxScorer ... That approach has been reverted. Instead, this change (fe86ceb) now makes DisjunctionMaxBulkScorer start with a window size of 1 and ...
shimpeko 11.4 days ago:	I added test case that are closer to my query which has dismax + constant_score as https:// ... Looking at the following benchmark result, I think I can say that the changes on this PR has ... .

#15508 PR: Use native vectorization in Lucene

2.1 days ago 49 comments 0 votes 0 watches dweiss, github-actions[bot], goankur, rmuir, shubhamvishu

Description This is continuation of the work @goankur started in https://github.com/apache/ ... Quoting the comment below from the initial PR.

dweiss 2.1 days ago:	Thank you.
shubhamvishu 2.3 days ago:	Thank you @dweiss ! I'll wait for a few days to see if anyone has more feedback and then merge.

«
1
2
3
4
5
»

2,521 issues

[21.2 msec search, 22.1 msec total]