On Thu, 2015-03-05 at 21:14 +0100, lei wrote:

You present a very interesting observation. I have not noticed what you
describe, but on the other hand we have not done comparative speed
tests.

> q=*:*&fq=country:"US"&fq=category:112

First observation: Your query is '*:*, which is a "magic" query. Non-DV
faceting has optimizations both for this query (although that ought to
be disabled due to the fq) and for the "inverse" case where there are
more hits than non-hits. Perhaps you could test with a handful of
queries, which has different result sizes?

> &facet=on&facet.sort=index&facet.mincount=1&facet.limit=2000

The combination of index order and a high limit might be an explanation:
When resolving the Strings of the facet result, non-DV will perform
ordinal-lookup, which is fast when done in monotonic rising order
(sort=index) and if the values are close (limit=2000). I do not know if
DV benefits the same way.

On the other hand, your limit seems to apply only to material, so it
could be that the real number of unique values is low and you just set
the limit to 2000 to be sure you get everything?

> &facet.field=manufacturer&facet.field=seller&facet.field=material
> &f.manufacturer.facet.mincount=1&f.manufacturer.facet.sort=count&f.manufacturer.facet.limit=100
> &f.seller.facet.mincount=1&f.seller.facet.sort=count&f.seller.facet.limit=100
> &f.material.facet.mincount=1&sort=score+desc

How large is your index in bytes, how many documents does it contain and
is it single-shard or cloud? Could you paste the loglines containing
"UnInverted field", which describes the number of unique values and size
of your facet fields?

- Toke Eskildsen, State and University Library, Denmark


Reply via email to