Re: [I] `mergeThreadCount` is both a variable and a method in the `ConcurrentMergeScheduler` [lucene]
vigyasharma closed issue #13114: `mergeThreadCount` is both a variable and a method in the `ConcurrentMergeScheduler` URL: https://github.com/apache/lucene/issues/13114 -- 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] Rename `mergeThreadCount` in ConcurrentMergeScheduler to avoid clashing with method of the same name [lucene]
vigyasharma merged PR #14171: URL: https://github.com/apache/lucene/pull/14171 -- 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] Support modifying segmentInfos.counter in IndexWriter [lucene]
vigyasharma commented on PR #14417: URL: https://github.com/apache/lucene/pull/14417#issuecomment-2764422079 Also, IIUC `IndexWriter#advanceSegmentInfosVersion()` was added to handle similar scenarios for NRT replication (Lucene's native segment replication implementation). I'm curious why we didn't run into the need to advance `SegmentInfos#counter` at that time. Do you remember, @mikemccand (I know it's been a while! (: )? -- 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] Allow skip cache factor to be updated dynamically [lucene]
kkewwei commented on PR #14412: URL: https://github.com/apache/lucene/pull/14412#issuecomment-2764949091 Thank you for your reply. I understand your perspective. You aim to optimize execution efficiency rather than focus on cache optimization. In certain rare scenarios, the querycache memory becomes full. To rectify the querycache situation, we are currently compelled to restart the JVM, which differs from your line of thought. I'm wondering if it would be feasible to expose all querycache cache APIs and eliminate any cache strategies within Lucene itself. If Lucene already has a querycache, then upper - level services like Elasticsearch or OpenSearch could refrain from implementing their own querycache. Please ignore this suggestion if it doesn't seem viable. -- 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] PointInSetQuery clips segments by lower and upper [lucene]
hanbj commented on code in PR #14268:
URL: https://github.com/apache/lucene/pull/14268#discussion_r2020443439
##
lucene/core/src/java/org/apache/lucene/search/PointInSetQuery.java:
##
@@ -108,6 +110,8 @@ protected PointInSetQuery(String field, int numDims, int
bytesPerDim, Stream pac
}
if (previous == null) {
previous = new BytesRefBuilder();
+lowerPoint = new byte[bytesPerDim * numDims];
+System.arraycopy(current.bytes, current.offset, lowerPoint, 0,
lowerPoint.length);
Review Comment:
You're right, usually the length of the copied array is used.
--
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] PointInSetQuery clips segments by lower and upper [lucene]
hanbj commented on code in PR #14268:
URL: https://github.com/apache/lucene/pull/14268#discussion_r2020445557
##
lucene/core/src/java/org/apache/lucene/search/PointInSetQuery.java:
##
@@ -153,6 +162,21 @@ public ScorerSupplier scorerSupplier(LeafReaderContext
context) throws IOExcepti
return null;
}
+if (values.getDocCount() == 0) {
Review Comment:
I am referring to the implementation in PointRangeQuery here.
--
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] PointInSetQuery clips segments by lower and upper [lucene]
hanbj commented on code in PR #14268:
URL: https://github.com/apache/lucene/pull/14268#discussion_r2020445151
##
lucene/core/src/java/org/apache/lucene/search/PointInSetQuery.java:
##
@@ -153,6 +162,21 @@ public ScorerSupplier scorerSupplier(LeafReaderContext
context) throws IOExcepti
return null;
}
+if (values.getDocCount() == 0) {
+ return null;
+} else if (lowerPoint != null && upperPoint != null) {
Review Comment:
This has been modified.
--
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] quick exit on filter query matching no docs when rewriting knn query [lucene]
jpountz commented on PR #14418: URL: https://github.com/apache/lucene/pull/14418#issuecomment-2764554455 Thank you, that makes sense. So in the case when the filter rewrites to MatchNoDocsQuery, `IndexSearcher#search` would now return immediately, while it may currently need to wait for tasks to be submitted (if the queue is not empty). Can you add a CHANGES entry? -- 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] A specialized Trie for Block Tree Index [lucene]
gf2121 commented on code in PR #14333:
URL: https://github.com/apache/lucene/pull/14333#discussion_r2006853334
##
lucene/core/src/java/org/apache/lucene/codecs/lucene90/blocktree/TrieBuilder.java:
##
@@ -0,0 +1,552 @@
+/*
+ * 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.codecs.lucene90.blocktree;
+
+import java.io.IOException;
+import java.util.ArrayDeque;
+import java.util.Deque;
+import java.util.Iterator;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.ListIterator;
+import java.util.function.BiConsumer;
+import org.apache.lucene.store.DataOutput;
+import org.apache.lucene.store.IndexOutput;
+import org.apache.lucene.store.RandomAccessInput;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefBuilder;
+
+/** TODO make it a more memory efficient structure */
+class TrieBuilder {
+
+ static final int SIGN_NO_CHILDREN = 0x00;
+ static final int SIGN_SINGLE_CHILD_WITH_OUTPUT = 0x01;
+ static final int SIGN_SINGLE_CHILD_WITHOUT_OUTPUT = 0x02;
+ static final int SIGN_MULTI_CHILDREN = 0x03;
+
+ static final int LEAF_NODE_HAS_TERMS = 1 << 5;
+ static final int LEAF_NODE_HAS_FLOOR = 1 << 6;
+ static final long NON_LEAF_NODE_HAS_TERMS = 1L << 1;
+ static final long NON_LEAF_NODE_HAS_FLOOR = 1L << 0;
+
+ /**
+ * The output describing the term block the prefix point to.
+ *
+ * @param fp describes the on-disk terms block which a trie node points to.
+ * @param hasTerms A boolean which will be false if this on-disk block
consists entirely of
+ * pointers to child blocks.
+ * @param floorData A {@link BytesRef} which will be non-null when a large
block of terms sharing
+ * a single trie prefix is split into multiple on-disk blocks.
+ */
+ record Output(long fp, boolean hasTerms, BytesRef floorData) {}
+
+ private enum Status {
+BUILDING,
+SAVED,
+DESTROYED
+ }
+
+ private static class Node {
+
+// The utf8 digit that leads to this Node, 0 for root node
+private final int label;
+// The children listed in order by their utf8 label
+private final LinkedList children;
+// The output of this node.
+private Output output;
+
+// Vars used during saving:
+
+// The file pointer point to where the node saved. -1 means the node has
not been saved.
+private long fp = -1;
+// The iterator whose next() point to the first child has not been saved.
+private Iterator childrenIterator;
+
+Node(int label, Output output, LinkedList children) {
+ this.label = label;
+ this.output = output;
+ this.children = children;
+}
+ }
+
+ private Status status = Status.BUILDING;
+ final Node root = new Node(0, null, new LinkedList<>());
+
+ static TrieBuilder bytesRefToTrie(BytesRef k, Output v) {
+return new TrieBuilder(k, v);
+ }
+
+ private TrieBuilder(BytesRef k, Output v) {
+if (k.length == 0) {
+ root.output = v;
+ return;
+}
+Node parent = root;
+for (int i = 0; i < k.length; i++) {
+ int b = k.bytes[i + k.offset] & 0xFF;
+ Output output = i == k.length - 1 ? v : null;
+ Node node = new Node(b, output, new LinkedList<>());
+ parent.children.add(node);
+ parent = node;
+}
+ }
+
+ /**
+ * Absorb all (K, V) pairs from the given trie into this one. The given trie
builder should not
+ * have key that already exists in this one, otherwise a {@link
IllegalArgumentException } will be
+ * thrown and this trie will get destroyed.
+ *
+ * Note: the given trie will be destroyed after absorbing.
+ */
+ void absorb(TrieBuilder trieBuilder) {
+if (status != Status.BUILDING || trieBuilder.status != Status.BUILDING) {
+ throw new IllegalStateException("tries should be unsaved");
+}
+// Use a simple stack to avoid recursion.
+Deque stack = new ArrayDeque<>();
+stack.add(() -> absorb(this.root, trieBuilder.root, stack));
+while (!stack.isEmpty()) {
+ stack.pop().run();
+}
+trieBuilder.status = Status.DESTROYED;
+ }
+
+ private void absorb(Node n, Node add, Deque stack) {
+assert n.label == add.label;
+if (add.output != null) {
+ if (n.output != null) {
+
Re: [PR] Allow skip cache factor to be updated dynamically [lucene]
jpountz commented on PR #14412: URL: https://github.com/apache/lucene/pull/14412#issuecomment-2764454882 > I am wondering if we should also make maxRamBytesUsed dynamic as well. What is your use-case for tuning it? Related to my comment on the issue linked to this PR, I worry a bit about optimizing too much for query caching vs. making the query cache less relevant. To expand a bit more on this, for "good" queries, like term queries or FieldExistQuery that produce good iterators with a low up-front cost, memory would be better spent on the filesystem cache than on the query cache. Boolean queries recently had big improvements that makes the query cache less relevant. (annotations HS, HW and HX at https://benchmarks.mikemccandless.com/CountAndHighHigh.html and https://benchmarks.mikemccandless.com/CountOrHighHigh.html). So that makes the query cache mostly relevant for queries that have a high up-front cost, like point queries and multi-term queries. Rather than investing in the query cache for these queries, I would rather invest in making them behave better, e.g. recent work on vectorizing this up-front cost for `PointRangeQuery` so that it's less likely to be the bottleneck of query evaluation, or `IndexOrDocValuesQuery` to skip this up-front cost entirely when it's hurting more than helping. -- 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] Allow skip cache factor to be updated dynamically [lucene]
jpountz merged PR #14412: URL: https://github.com/apache/lucene/pull/14412 -- 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
