Anyway, that´s good news copy field does not increase indexe size in some circumstance: - the copied fields and the target field share the same datatype - the target field is not stored
this is tested on text fields On Wed, Dec 25, 2019 at 11:42:23AM +0100, Nicolas Paris wrote: > > On Wed, Dec 25, 2019 at 05:30:03AM -0500, Dave wrote: > > #2 you initially said you were talking about 1k documents. > > Hi Dave. Again, sorry for the confusion. This is 1k fields > (general_text), over 50M large documents copied into one _text_ field. > 4 shards, 40GB per shard in both case, with/without the _text_ field > > > > > > On Dec 25, 2019, at 3:07 AM, Nicolas Paris <nicolas.pa...@riseup.net> > > > wrote: > > > > > > > > >> > > >> If you are redoing the indexing after changing the schema and > > >> reloading/restarting, then you can ignore me. > > > > > > I am sorry to say that I have to ignore you. Indeed, my tests include > > > recreating the collection from scratch - with and without the copy > > > fields. > > > In both cases the index size is the same ! (while the _text_ field is > > > working correctly) > > > > > >> On Tue, Dec 24, 2019 at 05:32:09PM -0700, Shawn Heisey wrote: > > >>> On 12/24/2019 5:11 PM, Nicolas Paris wrote: > > >>> Do you mean "copy fields" is only an action of changing the schema ? > > >>> I was thinking it was adding a new field and eventually a new index to > > >>> the collection > > >> > > >> The copy that copyField does happens at index time. Reindexing is > > >> required > > >> after changing the schema, or nothing happens. > > >> > > >> If you are redoing the indexing after changing the schema and > > >> reloading/restarting, then you can ignore me. > > >> > > >> Thanks, > > >> Shawn > > >> > > > > > > -- > > > nicolas > > > > -- > nicolas > -- nicolas
