You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by lochri <lo...@web.de> on 2016/07/26 12:48:50 UTC

facet.query on text - recommended field type

I am experiencing very slow query time when using multiple facet.query on
large result sets (like 5 minutes).
I don't know how to optimize this, since it is not completely clear to me
how the facet.query works.
Currently my facet queries use tokenized text fields and contain wildcards
or even use complex phrase query.
The normal q query part uses the same queries but is acceptable fast (1
second).
Does the facet.query use exact same search (through term index) as the q
query does ?
I am always reading that fields used for faceting should be string or
keyword tokenized and docValues should be enabled.
Is this true for facet.query as well or is this meant for facet.field only ?



--
View this message in context: http://lucene.472066.n3.nabble.com/facet-query-on-text-recommended-field-type-tp4288940.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: facet.query on text - recommended field type

Posted by Erik Hatcher <er...@gmail.com>.
facet.query is really just a short-cut for numFound using that query standalone.

How many facet.query’s are you issuing?   And what is the QTime for all those queries when individually made like this:

   /select?q=<facet.query.N>&rows=0

If one of your queries is “slow” - you mention wildcards and complex phrase query, so definitely some red flags!  If you’re making a bunch of those types of slow queries as facet.query’s, then it adds up (or maybe worse if we’re talking a sharded environment?)

No, the docValues/string/keyword considerations do no apply to facet.query.    The field(s) you need to query for facet.query need to be typed per the needs of the query itself, which often is useful to be tokenized text fields.  By all means, use the right field types for what you’d use to issue the same standalone query as above.

Consider this sort of example, using facet.query to give counts on precise to fuzzy queries:

  /select?q=*:*
        &my_facet_q=smith
	&facet=on
	&facet.query={!field f=name_s v=$my_facet_q}
	&facet.query={!field f=name_t v=$my_facet_q}
	&facet.query={!field f=name_phonetic v=$my_facet_q}

Assuming “name” is copyFielded into a string (name_s), basic tokenized (name_t), and phonetic (name_phonetic), this example will show the counts of each of those _levels_ of matching.

If you’re getting heavy into wildcards and complex phrases, I’d love to see some examples and compare notes.  I love what facet.query offers, and it’s one of Solr’s powerful little known gems.

	Erik


> On Jul 26, 2016, at 8:48 AM, lochri <lo...@web.de> wrote:
> 
> I am experiencing very slow query time when using multiple facet.query on
> large result sets (like 5 minutes).
> I don't know how to optimize this, since it is not completely clear to me
> how the facet.query works.
> Currently my facet queries use tokenized text fields and contain wildcards
> or even use complex phrase query.
> The normal q query part uses the same queries but is acceptable fast (1
> second).
> Does the facet.query use exact same search (through term index) as the q
> query does ?
> I am always reading that fields used for faceting should be string or
> keyword tokenized and docValues should be enabled.
> Is this true for facet.query as well or is this meant for facet.field only ?
> 
> 
> 
> --
> View this message in context: http://lucene.472066.n3.nabble.com/facet-query-on-text-recommended-field-type-tp4288940.html
> Sent from the Solr - User mailing list archive at Nabble.com.