Re: [PR] Avoid SegmentTermsEnumFrame reload block. [lucene]
vsop-479 commented on PR #13253: URL: https://github.com/apache/lucene/pull/13253#issuecomment-2283279880 Conflicts resolved. -- 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
Re: [PR] Terminate automaton after matched the whole prefix for PrefixQuery. [lucene]
vsop-479 commented on PR #13072: URL: https://github.com/apache/lucene/pull/13072#issuecomment-2283359055 Conflicts resolved. -- 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
Re: [I] TermsQuery as MultiTermQuery can dramatically overestimate its cost [lucene]
romseygeek commented on issue #12483: URL: https://github.com/apache/lucene/issues/12483#issuecomment-2283377281 Hey @gsmiller, thanks for the ping! I'm working elsewhere now, but IIRC @mayya-sharipova was looking at similar issues in the past so may be able to reproduce the issue and see if this has improved things? -- 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
Re: [PR] These attributes are better for the final state(#13628) [lucene]
mrhbj commented on code in PR #13630:
URL: https://github.com/apache/lucene/pull/13630#discussion_r1713395891
##
lucene/backward-codecs/src/java/org/apache/lucene/backward_codecs/lucene99/Lucene99SkipWriter.java:
##
@@ -46,8 +46,8 @@
* uptos(position, payload). 4. start offset.
*/
public final class Lucene99SkipWriter extends MultiLevelSkipListWriter {
- private int[] lastSkipDoc;
- private long[] lastSkipDocPointer;
+ private final int[] lastSkipDoc;
+ private final long[] lastSkipDocPointer;
private long[] lastSkipPosPointer;
private long[] lastSkipPayPointer;
Review Comment:
@gsmiller I have did that in #13639
--
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
Re: [I] Try applying bipartite graph reordering to KNN graph node ids [lucene]
jpountz commented on issue #13565: URL: https://github.com/apache/lucene/issues/13565#issuecomment-2284000709 This sounds to me like you are considering renumbering node IDs in the HNSW graph without renumbering doc IDs. I'm curious if you considered renumbering doc IDs like BPIndexReorderer? -- 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
Re: [PR] Get better cost estimate on MultiTermQuery over few terms [lucene]
gsmiller commented on PR #13201: URL: https://github.com/apache/lucene/pull/13201#issuecomment-2284078553 Thanks @msfroh. Yeah, I think it's worth exploring as long as there isn't something expensive-ish hiding in the weight creation of `BooleanQuery`. Thanks again! -- 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
Re: [I] TermsQuery as MultiTermQuery can dramatically overestimate its cost [lucene]
gsmiller commented on issue #12483: URL: https://github.com/apache/lucene/issues/12483#issuecomment-2284079513 Got it, thanks @romseygeek -- 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
Re: [PR] These attributes are better for the final state(#13628)（#13630） [lucene]
gsmiller merged PR #13639: URL: https://github.com/apache/lucene/pull/13639 -- 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
Re: [PR] These attributes are better for the final state(#13628)（#13630） [lucene]
gsmiller commented on PR #13639: URL: https://github.com/apache/lucene/pull/13639#issuecomment-2284111753 @mrhbj merged, thanks! -- 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
Re: [PR] These attributes are better for the final state(#13628) [lucene]
gsmiller commented on PR #13630: URL: https://github.com/apache/lucene/pull/13630#issuecomment-2284113028 Closing in favor of #13639 -- 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
Re: [I] These attributes are better for the final state [lucene]
gsmiller commented on issue #13628: URL: https://github.com/apache/lucene/issues/13628#issuecomment-2284113497 Addressed in #13639 -- 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
Re: [PR] These attributes are better for the final state(#13628) [lucene]
gsmiller closed pull request #13630: These attributes are better for the final state(#13628) URL: https://github.com/apache/lucene/pull/13630 -- 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
Re: [PR] Compute facets while collecting [lucene]
gsmiller merged PR #13568: URL: https://github.com/apache/lucene/pull/13568 -- 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
[PR] Backport #13568 [lucene]
gsmiller opened a new pull request, #13645: URL: https://github.com/apache/lucene/pull/13645 (no comment) -- 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
Re: [PR] Backport #13568 [lucene]
stefanvodita commented on PR #13645: URL: https://github.com/apache/lucene/pull/13645#issuecomment-2284385447 I'm surprised at how large the [spotless commit](https://github.com/apache/lucene/pull/13645/commits/fb2c0c50705a6a62bd93d4a270ad113a2e82283e) is. I assume it was just `gradlew tidy` and most code should have already been well formatted. -- 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
Re: [PR] Backport #13568 [lucene]
gsmiller commented on PR #13645: URL: https://github.com/apache/lucene/pull/13645#issuecomment-2284392144 @stefanvodita > I'm surprised at how large the [spotless commit](https://github.com/apache/lucene/pull/13645/commits/fb2c0c50705a6a62bd93d4a270ad113a2e82283e) is. I assume it was just gradlew tidy and most code should have already been well formatted. I think what you're seeing is mainly where I had to manually resolve conflicts in the drill-sideways stuff and I was doing it in an editor that kind of botched whitespace, etc. There's a bit indentation change because of bulkScorer moving back out of scoreSupplier among some other stuff... -- 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
Re: [PR] Backport #13568 [lucene]
epotyom commented on code in PR #13645:
URL: https://github.com/apache/lucene/pull/13645#discussion_r1714080529
##
lucene/facet/src/java/org/apache/lucene/facet/DrillSideways.java:
##
@@ -240,46 +242,43 @@ public DrillSidewaysResult search(DrillDownQuery query,
Collector hitCollector)
int numDims = drillDownDims.size();
FacetsCollectorManager drillDownCollectorManager =
createDrillDownFacetsCollectorManager();
+final CollectorOwner
drillDownCollectorOwner;
+if (drillDownCollectorManager != null) {
+ drillDownCollectorOwner = new
CollectorOwner<>(drillDownCollectorManager);
+} else {
+ drillDownCollectorOwner = null;
+}
-FacetsCollectorManager[] drillSidewaysFacetsCollectorManagers =
-new FacetsCollectorManager[numDims];
+final List> drillSidewaysCollectorOwners = new
ArrayList<>(numDims);
for (int i = 0; i < numDims; i++) {
- drillSidewaysFacetsCollectorManagers[i] = new FacetsCollectorManager();
+ drillSidewaysCollectorOwners.add(
+ new CollectorOwner<>(createDrillSidewaysFacetsCollectorManager()));
}
DrillSidewaysQuery dsq =
new DrillSidewaysQuery(
baseQuery,
-drillDownCollectorManager,
-drillSidewaysFacetsCollectorManagers,
+drillDownCollectorOwner,
+drillSidewaysCollectorOwners,
drillDownQueries,
scoreSubDocsAtOnce());
searcher.search(dsq, hitCollector);
FacetsCollector drillDownCollector;
-if (drillDownCollectorManager != null) {
- drillDownCollector =
drillDownCollectorManager.reduce(dsq.managedDrillDownCollectors);
+if (drillDownCollectorOwner != null) {
+ drillDownCollector = drillDownCollectorOwner.getResult();
} else {
drillDownCollector = null;
}
-FacetsCollector[] drillSidewaysCollectors = new FacetsCollector[numDims];
-int numSlices = dsq.managedDrillSidewaysCollectors.size();
-
+final String[] drillSidewaysDims = query.getDims().keySet().toArray(new
String[0]);
+final FacetsCollector[] drillSidewaysCollectors = new
FacetsCollector[numDims];
for (int dim = 0; dim < numDims; dim++) {
- List facetsCollectorsForDim = new
ArrayList<>(numSlices);
-
- for (int slice = 0; slice < numSlices; slice++) {
-
facetsCollectorsForDim.add(dsq.managedDrillSidewaysCollectors.get(slice)[dim]);
- }
-
drillSidewaysCollectors[dim] =
-
drillSidewaysFacetsCollectorManagers[dim].reduce(facetsCollectorsForDim);
+ (FacetsCollector) drillSidewaysCollectorOwners.get(dim).getResult();
Review Comment:
[nit] I think we can avoid casting here if we add types to
`drillSidewaysCollectorOwners`, but given that this method is to be deprecated,
I think it's fine to keep casting.
```
final List>
drillSidewaysCollectorOwners = ...
```
--
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
Re: [I] TermsQuery as MultiTermQuery can dramatically overestimate its cost [lucene]
gsmiller commented on issue #12483: URL: https://github.com/apache/lucene/issues/12483#issuecomment-2284479926 @mayya-sharipova do you have any additional information on this regression by chance? I know you did some work back in #13454 to help in this space, then @msfroh did work in #13201 to build on your change for better cost estimation. There's definitely still a situation where we dramatically over-estimate cost (when there are > 16 terms and it's not a PK-like field), but I'd be curious if we have real-world scenarios where we experience this that might motivate us to continue pursuing better cost estimation strategies. Thoughts? -- 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
Re: [I] These attributes are better for the final state [lucene]
gsmiller closed issue #13628: These attributes are better for the final state URL: https://github.com/apache/lucene/issues/13628 -- 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
[PR] Avoid rare random test failures in TestLongValueFacetCounts [lucene]
gsmiller opened a new pull request, #13646: URL: https://github.com/apache/lucene/pull/13646 When backporting GH#13568 I realized we have some incorrect usages of RandomNumbers#randomIntBetween in TestLongValueFacetCounts. We use this in place of Random#nextInt for 9x code to work with jdk11, but #nextInt expects the upper bound to be exclusive while RandomNumbers is inclusive. -- 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
Re: [PR] Backport #13568 [lucene]
gsmiller merged PR #13645: URL: https://github.com/apache/lucene/pull/13645 -- 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
Re: [PR] Avoid rare random test failures in TestLongValueFacetCounts [lucene]
gsmiller closed pull request #13646: Avoid rare random test failures in TestLongValueFacetCounts URL: https://github.com/apache/lucene/pull/13646 -- 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
Re: [I] `gradlew eclipse` no longer works [lucene]
dweiss commented on issue #13638: URL: https://github.com/apache/lucene/issues/13638#issuecomment-2284748381 Hi Uwe. Sorry, I was away on holidays. The cr-lf warning is caused by normalization in .gitattributes: ``` # Ignore all differences in line endings for the lock file. versions.lock text eol=lf versions.toml text eol=lf ``` Which git version are you using? I ask because I don't see this message. I'm also not sure how you ended up with crlfs in that file. I'll take a look at the eclipse issue. I don't think I've changed anything that could affect it - maybe it's something indirect. -- 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
Re: [PR] Optimize decoding blocks of postings using the vector API. [lucene]
jpountz commented on PR #13636: URL: https://github.com/apache/lucene/pull/13636#issuecomment-2284765651 @uschindler @rmuir Any objections to merging this PR? -- 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
Re: [PR] Optimize decoding blocks of postings using the vector API. [lucene]
jpountz commented on code in PR #13636:
URL: https://github.com/apache/lucene/pull/13636#discussion_r1714276855
##
lucene/core/src/java21/org/apache/lucene/internal/vectorization/MemorySegmentPostingDecodingUtil.java:
##
@@ -0,0 +1,109 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.internal.vectorization;
+
+import java.io.IOException;
+import java.lang.foreign.MemorySegment;
+import java.nio.ByteOrder;
+import jdk.incubator.vector.LongVector;
+import jdk.incubator.vector.VectorOperators;
+import jdk.incubator.vector.VectorSpecies;
+import org.apache.lucene.store.IndexInput;
+
+final class MemorySegmentPostingDecodingUtil extends PostingDecodingUtil {
+
+ private static final VectorSpecies LONG_SPECIES =
+ PanamaVectorConstants.PRERERRED_LONG_SPECIES;
+
+ private final IndexInput in;
+ private final MemorySegment memorySegment;
+
+ MemorySegmentPostingDecodingUtil(IndexInput in, MemorySegment memorySegment)
{
+this.in = in;
+this.memorySegment = memorySegment;
+ }
+
+ @Override
+ public void readLongs(int count, long[] b) throws IOException {
+if (count < LONG_SPECIES.length()) {
+ in.readLongs(b, 0, count);
+} else {
+ long offset = in.getFilePointer();
+ long endOffset = offset + count * Long.BYTES;
+ int loopBound = LONG_SPECIES.loopBound(count - 1);
+ for (int i = 0;
+ i < loopBound;
+ i += LONG_SPECIES.length(), offset += LONG_SPECIES.length() *
Long.BYTES) {
+LongVector.fromMemorySegment(LONG_SPECIES, memorySegment, offset,
ByteOrder.LITTLE_ENDIAN)
Review Comment:
It was when reading 16 longs.
--
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
Re: [I] Compare the missing value with the top value even after the hit queue is full [lucene]
gsmiller commented on issue #13643: URL: https://github.com/apache/lucene/issues/13643#issuecomment-2284967452 Thanks for finding this (and for adding a test case)! Would it be possible to write your test such that it fails without your proposed change? As it's currently written, I believe it will pass even without your change. That would make the testing a little stronger. WDYT? -- 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
Re: [PR] Compare the missing value with the top value even after the hit queue is full [lucene]
gsmiller commented on PR #13644: URL: https://github.com/apache/lucene/pull/13644#issuecomment-2284968622 Thanks! I left you one comment in the corresponding issue you opened for this (sorry, meant to put it here in the PR). -- 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
Re: [PR] Use Max WAND optimizations with ToParentBlockJoinQuery when using ScoreMode.Max [lucene]
github-actions[bot] commented on PR #13587: URL: https://github.com/apache/lucene/pull/13587#issuecomment-2285117122 This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you for your contribution! -- 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
Re: [PR] Optimize decoding blocks of postings using the vector API. [lucene]
gsmiller commented on code in PR #13636:
URL: https://github.com/apache/lucene/pull/13636#discussion_r1714509772
##
lucene/core/src/java/org/apache/lucene/codecs/lucene912/ForUtil.java:
##
@@ -300,13 +301,14 @@ int numBytes(int bitsPerValue) {
return bitsPerValue << (BLOCK_SIZE_LOG2 - 3);
}
- private static void decodeSlow(int bitsPerValue, DataInput in, long[] tmp,
long[] longs)
+ private static void decodeSlow(
+ int bitsPerValue, IndexInput in, PostingDecodingUtil pdu, long[] tmp,
long[] longs)
Review Comment:
nit: looks like `in` is never actually referenced
##
lucene/core/src/java/org/apache/lucene/codecs/lucene912/ForUtil.java:
##
@@ -300,13 +301,14 @@ int numBytes(int bitsPerValue) {
return bitsPerValue << (BLOCK_SIZE_LOG2 - 3);
}
- private static void decodeSlow(int bitsPerValue, DataInput in, long[] tmp,
long[] longs)
+ private static void decodeSlow(
+ int bitsPerValue, IndexInput in, PostingDecodingUtil pdu, long[] tmp,
long[] longs)
Review Comment:
Also, I think this is generally true of all the decode* methods?
Hmm... ah, I see. There are a couple rare cases where you need `in` but not
`pdu` and the others are vice versa. And I assume it's easier for code
generation to make the argument list consistent. OK... :)
--
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
Re: [I] Lucene99FlatVectorsReader.getFloatVectorValues(): NPE: Cannot read field "vectorEncoding" because "fieldEntry" is null [lucene]
david-sitsky commented on issue #13626: URL: https://github.com/apache/lucene/issues/13626#issuecomment-2285416022 @benwtrent - many thanks for your advice. Switching to PerFieldKnnVectorsFormat fixed the issue for us. -- 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
