Hi Currently we do not provide the means to use a single SortedSetDVField for both faceting and sorting. You can add a SortedSetDVFacetField to a Document, then use FacetsConfig.build(), but that encodes all your dimensions under a single SSDV field. It's done for efficiency, since at search time, when you ask to count the different dimensions, we need to read a single field.
It might be worth it to explore sharing the same SSDV field for both faceting and sorting, and compare the performance implications of doing that (when faceting). if you want to try it, I suggest that you look at SortedSetDocValuesReaderState and see if you can use it for this task. Shai On Tue, Jul 8, 2014 at 9:50 AM, Sandeep Khanzode < sandeep_khanz...@yahoo.com.invalid> wrote: > Hi, > > I am using Lucene 4.7.2 and my primary use case for Lucene is to do three > things: (a) search, (b) sort by a number of fields for the search results, > and (c) facet on probably an equal number of fields (probably the most > standard use cases anyway). > > Let us say, I have a corpus of more than a 100m docs with each document > having approx. 10-15 fields excluding the content (body) which will also be > one of the fields. Out of 10-15, I have a requirement to have sorting > enabled on all 10-15 and the facets as well. That makes a total of approx. > ~45 fields to be indexed for various reasons, once for > String/Long/TextField, once for SortedDocValuesField, and once for > FacetField each. > > What will be the impact of this on the indexing operation w.r.t. the time > taken as well as the extra disk space required? Will it grow linearly with > the increase in the number of fields? > > What is the impact on the memory usage during search time? > > > I will attempt to benchmark some of these, but if you have any experience > with this, request you to share the details. Thanks, > > ----------------------- > Thanks n Regards, > Sandeep Ramesh Khanzode
