LantaoJin commented on PR #16214: URL: https://github.com/apache/lucene/pull/16214#issuecomment-4666575101
> Changing approximated search to exact search under the hood just because of an update feels wrong. Thanks @iverase . It's deliberately consistent with `updateDocument`/`updateDocValues`, which also defer graph/secondary-structure work to the next merge. The intended workflow for a bulk re-embed is: update in place (cheap writes, 49 fields untouched) → one `forceMerge`/normal merge rebuilds the graph **once**, optimally. The exact-search window is bounded by a merge you were going to run anyway, and ANN is restored after it. For workloads that can't tolerate that window, I'd add an **eager rebuild mode** as a follow-up: rebuild the field's graph at update time so approximate search stays intact on the updated segment, trading commit cost for unchanged read latency. (I had it implemented and pulled it to keep the default behavior aligned with the other in-place update APIs -- happy to bring it back behind an opt-in.) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
