: I'm comparing pivot faceting to json sub-faceting.
JSON Faceting originally didn't support any sort of refinement -- at that point it was (IMO) really only useful for getting approximate information about the facet buckets -- it you needed hierarchical facets/stats and wanted any sort of confidence as to their accuracy, I would have absolutely said you should use pivot faceting. Once (optional) refinement was added to JSON Faceting things got better -- but it was still just "two phase" refinement, and there weren't very many options for tuning how aggresive the refinement was. At that point I would have still recommended pivot faceting for usecases where you wanted confidence in the accuracy in determining the top buckets. Once *BOTH* the "overrequest" & "overrefine" params were added, it became possible to exert a lot of control over how much refinement is done, and how accurate the top buckets are -- and a long the way JSON faceting gained a lot of other additional features, optimizations, and bug fixes. At this point, I really don't recommend pivot faceting for any "real world" usecases I've seen. The one hypothetical usecase where pivot faceting *might* be better is if you needed to do *deeply* nested facets, on fields with huge numbers of terms, in a collection where your term/bucket distribution across shards is very imbalanced, and you really wanted to be completley confident that you were getting the best possible top buckets at every level of the nested buckets, even if the requests took much longer -- and that's because the pivot facets will make recursive refinement calls for each level of the nested facets, to ensure the stats and sub-facets of every bucket are populated by every shard. For most usecases though: the JSON facet "two phase" approach is much faster, works just fine by default, and can be made even better by tuning "overrequest" & "overrefine". -Hoss http://www.lucidworks.com/
