Changing one child rewrites the whole block period. However in-place updating child docValues is promising in theory, although I don't know how it works in practice.
On Thu, Feb 27, 2025 at 8:05 AM Uday Kumar <uday.p...@indiamart.com.invalid> wrote: > Hi all, > We are doing a POC on indexing nested documents in expectation of reducing > grouping overhead while querying time. > > On Prod Indexing, we are using the traditional approach of reindexing the > entire document if there is any change in any of the fields. [we reindex > ~2cr documents per day, FYI] > Solr Version: v9.6.1 > > But I have come across a caution in solr documentation: *DOC > < > https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-nested-documents.html#:~:text=By%20way%20of%20examples%3A%20nested,%2F%20colors)%20and%20supporting%20documentation%20( > >*, > where it says: *Solr must internally reindex an entire nested document tree > if there are updates to it.* > Which means If a root or parent has 1000 child documents, even with a > change in single document in any one of the fields, entire nested childs > are reindexed, which is not good enough. > > This made us rethink of performance gains that we will have, if nested > documents are used in production. > > If that's the case, pls let us know if there are any other solutions which > would help us in performance gains. > > *Note:* > We have already done POC on external file fields and In-Place updates where > we found they are not impactful for our project. > > *Thanks & Regards,* > *Uday Kumar* > -- Sincerely yours Mikhail Khludnev
