leaves12138 commented on code in PR #550:
URL: https://github.com/apache/paimon-rust/pull/550#discussion_r3612677337
##########
crates/paimon/src/table/vector_search_builder.rs:
##########
@@ -557,12 +566,29 @@ impl<'a> VectorSearchBuilder<'a> {
},
);
- let candidates = PkVectorOrchestrator::new(reader)
+ // Resolve the refine factor from the query options first, then fall
back to
+ // the table options; a positive factor over-fetches indexed
(approximate)
+ // candidates so the exact rerank below has a wider pool to reorder.
Factor 0
+ // (unset) leaves `indexed_limit == limit`, byte-identical to the
no-rerank
+ // path. The two option maps are kept distinct (query options passed
+ // separately from table options) so a broad query key cannot be
overridden
+ // by a more specific table key: query options take precedence as a
whole.
+ // `search_options` above is the merged view used only to drive the
ANN read.
+ let refine_factor = configured_refine_factor(
Review Comment:
`configured_refine_factor` is reached only after `PkVectorScan::plan()` and
the `plan.splits.is_empty()` early return above. As a result, an empty
PK-vector table accepts `refine_factor=0` or `refine_factor=abc` and returns a
normal empty reader, while the identical query starts failing as soon as the
table has a searchable split. Java resolves this option in the
`PrimaryKeyVectorRead` constructor before planning, and configuration validity
should not depend on whether data currently exists. Please resolve the
factor/search limit before the empty-plan return (ideally before planning/index
I/O) and add an empty-plan regression test.
--
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]
