Thanks Vincenzo! I will check the schema too.
On 2022/06/07 16:08:21 Vincenzo D'Amore wrote: > The easiest thing to do is double check your schema.xml and see how the > field type "string" is defined. > > On Tue, Jun 7, 2022 at 3:44 PM Poorna Murali <po...@gmail.com> wrote: > > > If docValues are enabled by default for string field, then the sort queries > > on the field will not occupy field cache and would rather rely on > > docValues. But in our case, it is filling up the field cache and that is > > the reason we are planning to enable docValues for that field. > > Is this functionality version specific? > > > > On 2022/06/07 12:35:39 Vincenzo D'Amore wrote: > > > "string" field type usually has "docValues"=true as default. > > > > > > On Tue, Jun 7, 2022 at 11:22 AM Poorna Murali <po...@gmail.com> > > > wrote: > > > > > > > Hi All, > > > > > > > > We have an id field(unique key) in our schema as follows, > > > > <field name=“id” type=“string” indexed=“true” stored=“true” > > required=“true” > > > > multiValued=“false”/> > > > > > > > > We are planning to introduce docValues to this field to save fieldcache > > > > space. My understanding on this is that, going forward all the sort or > > > > faceting done on id field will make use of docValues and since the > > stored > > > > flag is true for this field normal search will continue to retrieve id > > from > > > > stored fields.The field cache will then not have id field. > > > > > > > > > > > > Please correct me if my understanding is wrong. > > > > > > > > Also, will there be any other performance impact with this change, for > > > > example, query time taking longer than before? > > > > > > > > Thanks & Regards, > > > > Poorna > > > > > > > > > > > > > -- > > > Vincenzo D'Amore > > > > > > > > -- > Vincenzo D'Amore >
