[GitHub] [lucene] gf2121 commented on pull request #831: LUCENE-10315: Speed up DocIdsWriter by ForUtil (backport 9x)
gf2121 commented on PR #831: URL: https://github.com/apache/lucene/pull/831#issuecomment-1107810870 Benchmark result looks good, I'll merge. https://home.apache.org/~mikemccand/lucenebench/2022.04.23.18.02.58.html -- 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
[GitHub] [lucene] gf2121 merged pull request #831: LUCENE-10315: Speed up DocIdsWriter by ForUtil (backport 9x)
gf2121 merged PR #831: URL: https://github.com/apache/lucene/pull/831 -- 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
[jira] [Commented] (LUCENE-10315) Speed up BKD leaf block ids codec by a 512 ints ForUtil
[
https://issues.apache.org/jira/browse/LUCENE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527143#comment-17527143
]
ASF subversion and git services commented on LUCENE-10315:
--
Commit d0ece89b391dddf97da37089cbde417fd311148c in lucene's branch
refs/heads/branch_9x from gf2121
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=d0ece89b391 ]
LUCENE-10315: Speed up DocIdsWriter by ForUtil (#797)
> Speed up BKD leaf block ids codec by a 512 ints ForUtil
> ---
>
> Key: LUCENE-10315
> URL: https://issues.apache.org/jira/browse/LUCENE-10315
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Feng Guo
>Assignee: Feng Guo
>Priority: Major
> Attachments: addall.svg, cpu_profile_baseline.html,
> cpu_profile_path.html
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Elasticsearch (which based on lucene) can automatically infers types for
> users with its dynamic mapping feature. When users index some low cardinality
> fields, such as gender / age / status... they often use some numbers to
> represent the values, while ES will infer these fields as {{{}long{}}}, and
> ES uses BKD as the index of {{long}} fields. When the data volume grows,
> building the result set of low-cardinality fields will make the CPU usage and
> load very high.
> This is a flame graph we obtained from the production environment:
> [^addall.svg]
> It can be seen that almost all CPU is used in addAll. When we reindex
> {{long}} to {{{}keyword{}}}, the cluster load and search latency are greatly
> reduced ( We spent weeks of time to reindex all indices... ). I know that ES
> recommended to use {{keyword}} for term/terms query and {{long}} for range
> query in the document, but there are always some users who didn't realize
> this and keep their habit of using sql database, or dynamic mapping
> automatically selects the type for them. All in all, users won't realize that
> there would be such a big difference in performance between {{long}} and
> {{keyword}} fields in low cardinality fields. So from my point of view it
> will make sense if we can make BKD works better for the low/medium
> cardinality fields.
> As far as i can see, for low cardinality fields, there are two advantages of
> {{keyword}} over {{{}long{}}}:
> 1. {{ForUtil}} used in {{keyword}} postings is much more efficient than BKD's
> delta VInt, because its batch reading (readLongs) and SIMD decode.
> 2. When the query term count is less than 16, {{TermsInSetQuery}} can lazily
> materialize of its result set, and when another small result clause
> intersects with this low cardinality condition, the low cardinality field can
> avoid reading all docIds into memory.
> This ISSUE is targeting to solve the first point. The basic idea is trying to
> use a 512 ints {{ForUtil}} for BKD ids codec. I benchmarked this optimization
> by mocking some random {{LongPoint}} and querying them with
> {{PointInSetQuery}}.
> *Benchmark Result*
> |doc count|field cardinality|query point|baseline QPS|candidate QPS|diff
> percentage|
> |1|32|1|51.44|148.26|188.22%|
> |1|32|2|26.8|101.88|280.15%|
> |1|32|4|14.04|53.52|281.20%|
> |1|32|8|7.04|28.54|305.40%|
> |1|32|16|3.54|14.61|312.71%|
> |1|128|1|110.56|350.26|216.81%|
> |1|128|8|16.6|89.81|441.02%|
> |1|128|16|8.45|48.07|468.88%|
> |1|128|32|4.2|25.35|503.57%|
> |1|128|64|2.13|13.02|511.27%|
> |1|1024|1|536.19|843.88|57.38%|
> |1|1024|8|109.71|251.89|129.60%|
> |1|1024|32|33.24|104.11|213.21%|
> |1|1024|128|8.87|30.47|243.52%|
> |1|1024|512|2.24|8.3|270.54%|
> |1|8192|1|.33|5000|50.00%|
> |1|8192|32|139.47|214.59|53.86%|
> |1|8192|128|54.59|109.23|100.09%|
> |1|8192|512|15.61|36.15|131.58%|
> |1|8192|2048|4.11|11.14|171.05%|
> |1|1048576|1|2597.4|3030.3|16.67%|
> |1|1048576|32|314.96|371.75|18.03%|
> |1|1048576|128|99.7|116.28|16.63%|
> |1|1048576|512|30.5|37.15|21.80%|
> |1|1048576|2048|10.38|12.3|18.50%|
> |1|8388608|1|2564.1|3174.6|23.81%|
> |1|8388608|32|196.27|238.95|21.75%|
> |1|8388608|128|55.36|68.03|22.89%|
> |1|8388608|512|15.58|19.24|23.49%|
> |1|8388608|2048|4.56|5.71|25.22%|
> The indices size is reduced for low cardinality fields and flat for high
> cardinality fields.
> {code:java}
> 113Mindex_1_doc_32_cardinality_baseline
> 114Mindex_1_doc_32_cardinality_candidate
> 140Mindex_1_doc_128_cardinality_baseline
> 133Mindex_1_doc_128_cardinality_candidate
> 193Mindex_1_doc_1024_cardinality_baseline
> 174Mindex_1_doc
[GitHub] [lucene-solr] epugh commented on pull request #2651: SOLR-16110 Using Schema/Config API breaks the File-Upload of Config Set File
epugh commented on PR #2651: URL: https://github.com/apache/lucene-solr/pull/2651#issuecomment-1107839649 I was trying to figure out why I couldn't find this PR, and realized that this is against the `lucene-solr` repo... Not the new `solr` repo. I'm going to copy the code over and see how it goes... ;-) -- 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
[GitHub] [lucene-solr] madrob commented on a diff in pull request #2651: SOLR-16110 Using Schema/Config API breaks the File-Upload of Config Set File
madrob commented on code in PR #2651:
URL: https://github.com/apache/lucene-solr/pull/2651#discussion_r857126726
##
solr/core/src/java/org/apache/solr/cloud/ZkController.java:
##
@@ -2503,7 +2503,8 @@ public static int
persistConfigResourceToZooKeeper(ZkSolrResourceLoader zkLoader
public static void touchConfDir(ZkSolrResourceLoader zkLoader) {
SolrZkClient zkClient = zkLoader.getZkController().getZkClient();
try {
- zkClient.setData(zkLoader.getConfigSetZkPath(), new byte[]{0}, true);
+ byte[] currentData = zkClient.getData(zkLoader.getConfigSetZkPath(),
null, null, true);
+ zkClient.setData(zkLoader.getConfigSetZkPath(), currentData, true);
Review Comment:
Probably a race condition 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
[GitHub] [lucene-solr] epugh commented on a diff in pull request #2651: SOLR-16110 Using Schema/Config API breaks the File-Upload of Config Set File
epugh commented on code in PR #2651:
URL: https://github.com/apache/lucene-solr/pull/2651#discussion_r857128799
##
solr/core/src/java/org/apache/solr/cloud/ZkController.java:
##
@@ -2503,7 +2503,8 @@ public static int
persistConfigResourceToZooKeeper(ZkSolrResourceLoader zkLoader
public static void touchConfDir(ZkSolrResourceLoader zkLoader) {
SolrZkClient zkClient = zkLoader.getZkController().getZkClient();
try {
- zkClient.setData(zkLoader.getConfigSetZkPath(), new byte[]{0}, true);
+ byte[] currentData = zkClient.getData(zkLoader.getConfigSetZkPath(),
null, null, true);
+ zkClient.setData(zkLoader.getConfigSetZkPath(), currentData, true);
Review Comment:
Do you have a suggestion here? I'm going through and manually testing this
to confirm the problemHowever, if you had a code fix, I'd love to see
it pushed up ;-)
--
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
[GitHub] [lucene-solr] madrob commented on a diff in pull request #2651: SOLR-16110 Using Schema/Config API breaks the File-Upload of Config Set File
madrob commented on code in PR #2651:
URL: https://github.com/apache/lucene-solr/pull/2651#discussion_r857132730
##
solr/core/src/java/org/apache/solr/cloud/ZkController.java:
##
@@ -2503,7 +2503,8 @@ public static int
persistConfigResourceToZooKeeper(ZkSolrResourceLoader zkLoader
public static void touchConfDir(ZkSolrResourceLoader zkLoader) {
SolrZkClient zkClient = zkLoader.getZkController().getZkClient();
try {
- zkClient.setData(zkLoader.getConfigSetZkPath(), new byte[]{0}, true);
+ byte[] currentData = zkClient.getData(zkLoader.getConfigSetZkPath(),
null, null, true);
+ zkClient.setData(zkLoader.getConfigSetZkPath(), currentData, true);
Review Comment:
I don't have an IDE in front of me, but there's a flag to setData I think
that lets us fail if the node already exists to avoid overwriting the current
data.
--
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
[GitHub] [lucene] rmuir commented on pull request #816: LUCENE-10519: ThreadLocal.remove under G1GC takes 100% CPU
rmuir commented on PR #816: URL: https://github.com/apache/lucene/pull/816#issuecomment-1107875110 `./gradlew check` still fails. -- 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
[GitHub] [lucene] gautamworah96 commented on pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
gautamworah96 commented on PR #829: URL: https://github.com/apache/lucene/pull/829#issuecomment-1108049460 I've added a new revision that adds some more functionality, caught some bad edge cases and beasted the test for 2000 iters on a Mac. Only when I ran `./gradlew check` finally did I realize that the `io.File` class is forbidden :/ I'll find some time tomorrow and port the logic to `nio.Files`. -- 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
[GitHub] [lucene] rmuir commented on pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
rmuir commented on PR #829: URL: https://github.com/apache/lucene/pull/829#issuecomment-1108062297 i think we should avoid doing case-insensitivity here. maybe for another PR? I'd like to avoid listing tons of files as a side effect of Path resolve operations, it is many extra i/os. -- 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
[GitHub] [lucene] gautamworah96 commented on pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
gautamworah96 commented on PR #829: URL: https://github.com/apache/lucene/pull/829#issuecomment-1108069323 > I'd like to avoid listing tons of files as a side effect of Path resolve operations, it is many extra i/os. Yes I was concerned about this as well (probably need a cache here). + the added test breakage and complexity in the same PR. Removed that logic for now. -- 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
[GitHub] [lucene] gautamworah96 commented on a diff in pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
gautamworah96 commented on code in PR #829:
URL: https://github.com/apache/lucene/pull/829#discussion_r857252262
##
lucene/test-framework/src/java/org/apache/lucene/tests/mockfile/FilterPath.java:
##
@@ -270,7 +270,7 @@ public static Path unwrap(Path path) {
return Unwrappable.unwrapAll(path);
}
- private final Path wrap(Path other) {
+ final Path wrap(Path other) {
Review Comment:
Added in
[49ef22b](https://github.com/apache/lucene/pull/829/commits/49ef22b9b2de6f484937993cbbb65da7ed57f32b)
--
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
[GitHub] [lucene] gautamworah96 commented on a diff in pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
gautamworah96 commented on code in PR #829:
URL: https://github.com/apache/lucene/pull/829#discussion_r857255977
##
lucene/test-framework/src/java/org/apache/lucene/tests/mockfile/WindowsPath.java:
##
@@ -0,0 +1,62 @@
+/*
+ * 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.tests.mockfile;
+
+import java.nio.file.InvalidPathException;
+import java.nio.file.Path;
+import java.util.Arrays;
+import java.util.HashSet;
+
+class WindowsPath extends FilterPath {
+
+ static HashSet RESERVED_CHARACTERS =
+ new HashSet<>(Arrays.asList('<', '>', ':', '\"', '/', '\\', '|', '?',
'*'));
+
+ static HashSet RESERVED_NAMES =
+ new HashSet<>(
+ Arrays.asList(
+ "CON", "PRN", "AUX", "NUL", "COM1", "COM2", "COM3", "COM4",
"COM5", "COM6", "COM7",
+ "COM8", "COM9", "LPT1", "LPT2", "LPT3", "LPT4", "LPT5", "LPT6",
"LPT7", "LPT8",
+ "LPT9"));
+
+ WindowsPath(Path path, FilterFileSystem fileSystem) {
+super(path, fileSystem);
+ }
+
+ @Override
+ public Path resolve(Path other) {
+checkInvalidPath(other);
+return wrap(delegate.resolve(toDelegate(other)));
+ }
+
+ private void checkInvalidPath(Path other) {
+String fileName = other.toString();
Review Comment:
Using `other.getFileName().toString()` fixes the failing CI build but it
also allows cases like `foo/bar` to pass through (because the fileName is then
just `bar`). Needs more investigation
--
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
[GitHub] [lucene] gautamworah96 commented on a diff in pull request #829: LUCENE-10525 Improve WindowsFS emulation to catch invalid file names
gautamworah96 commented on code in PR #829:
URL: https://github.com/apache/lucene/pull/829#discussion_r857259974
##
lucene/test-framework/src/java/org/apache/lucene/tests/mockfile/WindowsPath.java:
##
@@ -0,0 +1,62 @@
+/*
+ * 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.tests.mockfile;
+
+import java.nio.file.InvalidPathException;
+import java.nio.file.Path;
+import java.util.Arrays;
+import java.util.HashSet;
+
+class WindowsPath extends FilterPath {
+
+ static HashSet RESERVED_CHARACTERS =
+ new HashSet<>(Arrays.asList('<', '>', ':', '\"', '/', '\\', '|', '?',
'*'));
+
+ static HashSet RESERVED_NAMES =
+ new HashSet<>(
+ Arrays.asList(
+ "CON", "PRN", "AUX", "NUL", "COM1", "COM2", "COM3", "COM4",
"COM5", "COM6", "COM7",
+ "COM8", "COM9", "LPT1", "LPT2", "LPT3", "LPT4", "LPT5", "LPT6",
"LPT7", "LPT8",
+ "LPT9"));
+
+ WindowsPath(Path path, FilterFileSystem fileSystem) {
+super(path, fileSystem);
+ }
+
+ @Override
+ public Path resolve(Path other) {
+checkInvalidPath(other);
+return wrap(delegate.resolve(toDelegate(other)));
+ }
+
+ private void checkInvalidPath(Path other) {
+String fileName = other.toString();
Review Comment:
Unix also handles this for us. Let's just rely on that instead of
duplicating that logic here. Linux tests will catch file names with a `/` in
them.
--
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
[GitHub] [lucene] zacharymorn opened a new pull request, #833: LUCENE-10411: Add NN vectors support to ExitableDirectoryReader
zacharymorn opened a new pull request, #833: URL: https://github.com/apache/lucene/pull/833 # Description / Solution Add NN vectors support to ExitableDirectoryReader # Tests * Added new test * Passed existing tests # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/lucene/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Lucene maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. -- 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
[jira] [Commented] (LUCENE-10411) Add NN vectors support to ExitableDirectoryReader
[ https://issues.apache.org/jira/browse/LUCENE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527308#comment-17527308 ] Zach Chen commented on LUCENE-10411: Hi [~jpountz] , I have created a PR for this. Could you please take a look and let me know your thoughts? > Add NN vectors support to ExitableDirectoryReader > - > > Key: LUCENE-10411 > URL: https://issues.apache.org/jira/browse/LUCENE-10411 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > This is currently unsupported. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-10436) Combine DocValuesFieldExistsQuery, NormsFieldExistsQuery and KnnVectorFieldExistsQuery into a single FieldExistsQuery?
[ https://issues.apache.org/jira/browse/LUCENE-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach Chen reassigned LUCENE-10436: -- Assignee: Zach Chen > Combine DocValuesFieldExistsQuery, NormsFieldExistsQuery and > KnnVectorFieldExistsQuery into a single FieldExistsQuery? > -- > > Key: LUCENE-10436 > URL: https://issues.apache.org/jira/browse/LUCENE-10436 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Assignee: Zach Chen >Priority: Minor > Time Spent: 6.5h > Remaining Estimate: 0h > > Now that we require consistency across data structures, we could merge > DocValuesFieldExistsQuery, NormsFieldExistsQuery and > KnnVectorFieldExistsQuery together into a FieldExistsQuery that would require > that the field indexes either norms, doc values or vectors? -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-10436) Combine DocValuesFieldExistsQuery, NormsFieldExistsQuery and KnnVectorFieldExistsQuery into a single FieldExistsQuery?
[ https://issues.apache.org/jira/browse/LUCENE-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach Chen resolved LUCENE-10436. Resolution: Done > Combine DocValuesFieldExistsQuery, NormsFieldExistsQuery and > KnnVectorFieldExistsQuery into a single FieldExistsQuery? > -- > > Key: LUCENE-10436 > URL: https://issues.apache.org/jira/browse/LUCENE-10436 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Time Spent: 6.5h > Remaining Estimate: 0h > > Now that we require consistency across data structures, we could merge > DocValuesFieldExistsQuery, NormsFieldExistsQuery and > KnnVectorFieldExistsQuery together into a FieldExistsQuery that would require > that the field indexes either norms, doc values or vectors? -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
