jerry-024 commented on code in PR #8000: URL: https://github.com/apache/paimon/pull/8000#discussion_r3528373646
########## paimon-eslib/src/main/java/org/apache/paimon/eslib/index/ESIndexGlobalIndexerFactory.java: ########## @@ -0,0 +1,123 @@ +/* + * 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.paimon.eslib.index; + +import org.apache.paimon.globalindex.GlobalIndexer; +import org.apache.paimon.globalindex.GlobalIndexerFactory; +import org.apache.paimon.options.Options; +import org.apache.paimon.types.DataField; + +import java.util.List; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.LinkedBlockingQueue; +import java.util.concurrent.ThreadPoolExecutor; +import java.util.concurrent.TimeUnit; + +/** + * Factory for creating ES multi-index global indexers. Supports vector (DiskBBQ/HNSW/Native), + * fulltext (BM25), and scalar fields. + */ +public class ESIndexGlobalIndexerFactory implements GlobalIndexerFactory { + + public static final String IDENTIFIER = "es-index"; + + private static final String READ_SEARCH_THREADS_KEY = + "global-index.es-index.read-search-threads"; + private static final int DEFAULT_READ_SEARCH_THREADS = -1; + + private static volatile ExecutorService readSearchExecutor; + private static final Object LOCK = new Object(); + + @Override + public String identifier() { + return IDENTIFIER; + } + + @Override + public boolean supportsFullTextSearch() { + // The ES index is a hybrid backend: a FULLTEXT-typed column (whether it is the primary + // index field or an extra field of a multi-column index) is served by Lucene full-text + // search. Without this override FullTextScanImpl filters out every es-index file and the + // planner full-text path returns nothing. + return true; Review Comment: I think there is still a correctness gap here. `FullTextScanImpl` now treats an `es-index` file as full-text coverage whenever the searched text column appears in either `indexFieldId` or `extraFieldIds`, because `ESIndexGlobalIndexerFactory.supportsFullTextSearch()` returns true at the index-type level. But `es-index` field capability is per field: a STRING field defaults to KEYWORD in `ESIndexOptions` unless an analyzer/type=fulltext is configured. A concrete case: 1. Rows [0, 99] are covered by a real full-text index on `title`. 2. Rows [100, 199] are covered only by a hybrid `es-index` whose primary field is `embedding` and whose extra field is `title`. 3. That `title` extra field has no analyzer configured, so inside the ES index it is KEYWORD, not FULLTEXT. 4. A query runs `full_text_search(title, {"match":{"query":"paimon"}})`. During planning, the `es-index` file for rows [100, 199] is still counted as full-text coverage for `title`, so `GlobalIndexCoverage.unindexedRanges(title)` will not add a raw fallback split for that range. During reading, `ESIndexGlobalIndexReader.visitFullTextSearch()` cannot serve FULLTEXT on the KEYWORD `title` field and returns empty/no-match. The result is that rows [100, 199] are skipped entirely, even though raw full-text fallback should have searched them. So I think the scan/coverage decision needs to be field-capability-aware, not only index-type-aware. Only ranges where the queried field is actually configured as FULLTEXT in that `es-index` should count as full-text indexed coverage. Otherwise those ranges should remain eligible for raw fallback. Could we add a regression test for this mixed-range case: one range covered by a real FULLTEXT index, another range covered only by an `es-index` where the searched text column is a KEYWORD extra field, and verify the latter range is still searched via raw fallback? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
