lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geert-Jan Brits <>
Subject Re: Consequences for using multivalued on all fields
Date Tue, 21 Dec 2010 16:54:04 GMT
You should be aware that the behavior of sorting on a multi-valued field is
undefined. After all, which of the multiple values should be used for
So if you need sorting on the field, you shouldn't make it multi-valued.


2010/12/21 J.J. Larrea <>

> Someone please correct me if I am wrong, but as far as I am aware index
> format is identical in either case.
> One benefit of allowing one to specify a field as single-valued is similar
> to specifying that a field is required: Providing a safeguard that index
> data conforms to requirements.  So making all fields multivalued forgoes
> that integrity check for fields which by definition should be singular.
> Also depending on the response writer and for the XMLResponseWriter the
> requested response version (see
> the multi-valued setting
> can determine whether the document values returned from a query will be
> scalars (eg. <str name="year">2010</str>) or arrays of scalars (<arr
> name="year"><str>2010</str></arr>), regardless of how many values
> actually stored.
> But the most significant gotcha of not specifying the actual arity (1 or N)
> arises if any of those fields is used for field-faceting: By default the
> field-faceting logic chooses a different algorithm depending on whether the
> field is multi-valued, and the default choice for multi-valued is only
> appropriate for a small set of enumerated values since it creates a filter
> query for each value in the set. And this can have a profound effect on Solr
> memory utilization. So if you are not relying on the field arity setting to
> select the algorithm, you or your users might need to specify it explicitly
> with the f.<field>.facet.method argument; see
> for more info.
> So while all-multivalued isn't a showstopper, if it were up to me I'd want
> to give users the option to specify arity and whether the field is required.
> - J.J.
> At 2:13 PM +0100 12/21/10, Tim TerlegÄrd wrote:
> >In our application we use dynamic fields and there can be about 50 of
> >them and there can be up to 100 million documents.
> >
> >Are there any disadvantages having multivalued=true on all fields in
> >the schema? An admin of the application can specify dynamic fields and
> >if they should be indexed or stored. Question is if we gain anything
> >by letting them to choose multivalued as well or if it just adds
> >complexity to the user interface?
> >
> >Thanks,
> >Tim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message