> So what will be added is just another set of pointers to each relevant
> term. That's not going to be very large. Probably
Hi Shawn. This explains much ! Thanks.
In case of text fields, the highlight is done on the source fields and
the _text_ field is only used for lookup. This behavior is
On 12/26/2019 1:21 PM, Nicolas Paris wrote:
Below a part of the managed-schema. There is 1k section* fields. The
second experience, I removed the copyField, droped the collection and
re-indexed the whole. To mesure the index size, I went to solr-cloud and
looked in the cloud part: 40GO per
The field is stored somewhere
> On Dec 26, 2019, at 3:22 PM, Nicolas Paris wrote:
>
> Hi Eric
>
> Below a part of the managed-schema. There is 1k section* fields. The
> second experience, I removed the copyField, droped the collection and
> re-indexed the whole. To mesure the index size, I
Hi Eric
Below a part of the managed-schema. There is 1k section* fields. The
second experience, I removed the copyField, droped the collection and
re-indexed the whole. To mesure the index size, I went to solr-cloud and
looked in the cloud part: 40GO per shard. I also look at the folder
size. I
This simply cannot be true unless the destination copyField is indexed=false,
docValues=false stored=false. I.e. “some circumstances” means there’s really no
use in using the copyField in the first place. I suppose that if you don’t
store any term vectors, no position information nothing
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
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,
#1 merry Xmas thing
#2 you initially said you were talking about 1k documents. That will not be a
large enough sample size to see the index size differences with this new field,
in any case the index size should never really matter. But if you go to a few
million you will notice the size has
> 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
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
> The action of changing the schema makes zero changes in the index. It
> merely changes how Solr interacts with the index.
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
On Tue, Dec 24,
On 12/24/2019 10:45 AM, Nicolas Paris wrote:
From my understanding, copy fields creates an new indexes from the
copied fields.
From my tests, I copied 1k textual fields into _text_ with copyFields.
As a result there is no increase in the size of the collection. All the
source fields are
Hi
>From my understanding, copy fields creates an new indexes from the
copied fields.
>From my tests, I copied 1k textual fields into _text_ with copyFields.
As a result there is no increase in the size of the collection. All the
source fields are indexed and stored. The _text_ field is indexed
13 matches
Mail list logo
