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

#16050 PR: Add SIMD-accelerated bulk range evaluation for dense numeric doc values

9.2 minutes ago 34 comments 0 votes 0 watches benwtrent, github-actions[bot], neoremind, romseygeek, sgup432

Description Numeric range queries on dense fields use DocValuesRangeIterator, which is a ... This works well, but for MAYBE blocks (where values partially overlap the query range), it still ... Since DocValuesRangeIterator is a TwoPhaseIterator, DenseConjunctionBulkScorer routes it through ...

benwtrent 9.2 minutes ago:	@sgup432 I do suggest having a "@Nightly" version of the doc count if we really need to have many ...
sgup432 12.3 minutes ago:	Yeah that is true for a unit test! I think this class needs some fixing, I was using to do some adhoc testing in ly local. Let me fix it and add more cases.

#16053 PR: Add an (optional) field-writer creation strategy to Lucene99FlatVectorsWriter

1.6 hours ago 2 comments 0 votes 0 watches github-actions[bot], ldematte

Lucene99FlatVectorsWriter hard-codes the per-field storage for vector values to an on-heap ... Different users of Lucene99FlatVectorsFormat may want to change how vectors are stored in memory; ... In particular, this PR adds a public constructor overload to Lucene99FlatVectorsWriter that accepts ...

ldematte 8 hours ago:

We could store FlatFieldVectorsWriters and FieldInfos separately in 2 arrays, but I think using a ...

#16062 PR: Add FlatFieldVectorsWriter#asKnnVectorValues

1.6 hours ago 1 comments 0 votes 0 watches ChrisHegarty, github-actions[bot], ldematte

FlatFieldVectorsWriter<T> exposes its accumulated vectors via List<T> getVectors(). This is both too generic and too prescriptive: - List<T> binds the return type to specific vector ... -it does not carry enough information with it (e.g. encoding, dimensions for sub-byte packed types, ...

ChrisHegarty 4.9 hours ago:

Nice! LGTM. I'm going to label this for milestone 10.5, so a changes entry can be added there for it.

#16047 PR: Join post-HNSW block rescore for diversifying child KNN (POC)

3.4 hours ago 1 comments 0 votes 0 watches benwtrent, github-actions[bot], iprithv

# Description This implements a proof of concept for sibling scoring in block join diversified ... . | children/parent | rescoreBlocks=false | rescoreBlocks=true | |----------------|------------- ...

iprithv 3.4 hours ago:

@benwtrent, would like to get your thoughts on this. thanks!

#16061 PR: Improve cost estimation in SortedSetDocValuesRangeQuery when using DocValuesSkipper

5.6 hours ago 6 comments 0 votes 0 watches github-actions[bot], iverase, romseygeek

I noticed that the current implementation always return values.cost() because we are delaying the ... This is because we need to do some lookups for resolving the ordinals of the query. Still when there is a skipper and the index is dense and used as primary sort, we have a very fast ...

iverase 5.6 hours ago:	I think that comment predates skippers and it is because the resolution of the ordinals. But sure, if we don't wan to to do any IO during the construction of the supplier we shouldn't do ... My question is, should we then modify SortedNumericDocValuesRangeQuery?
romseygeek 5.7 hours ago:	This is the bit that is called out as expensive below so I'm not sure if we should be doing it in ... A couple of weeks back we were discussing ways of improving cost estimates using skippers, so I ...

#16060 PR: Remove IOException from LeafReader#getSumDocFreq and LeafReader#getSumTotalTermFreq signatures

7.1 hours ago 0 comments 0 votes 0 watches github-actions[bot], iverase

These are the last ones of this saga. This time the SimpleText codec was again behaving wrong but already had a todo. relates https://github.com/apache/lucene/issues/16052

#16056 PR: Modernize collection#toArray calls

7.6 hours ago 1 comments 0 votes 0 watches benwtrent, github-actions[bot], vsop-479

Description It looks like there were still some old-style CollectiontoArray usages remaining ... I will try to enforce a ban on old-style (or just pre-sized array style) Collection#toArray calls.

benwtrent 7.6 hours ago:

seems like this should be backported to 10x as well right?

«
1
2
3
4
5
»

2,561 issues

[20.5 msec search, 21.5 msec total]