Thanks for the explanation, Joel. When you say the query/collapse needs to
be re-run, is this the facet component that needs to do this? The confusing
part is that the debug suggests the time is being spent in the query
component when faceting is enabled. My naive reading of your response would
give me the expectation that by enabling facets with facet=true, the facet
component would need to do additional work and so the qTime cost would be
paid by that component. Here is the debug I get for repeated hits against
/default?indent=on&q=*:*&wt=json&fq={!collapse+field=groupid}&facet=true&debugQuery=on:
"process": {
"time": 200.0,
"query": { "time": 200.0 },
"facet": { "time": 0.0 },
"facet_module": { "time": 0.0 },
"mlt": { "time": 0.0 },
"highlight": { "time": 0.0 },
"stats": { "time": 0.0 },
"expand": { "time": 0.0 },
"terms": { "time": 0.0 },
"debug": { "time": 0.0 }
}
Or perhaps the facet component uses the query component to rerun the query
and the time is billed to that component?
Regardless, is the lack of caching a known and ticketed issue? The
consensus across various other solr tickets regarding grouped search seems
to be to prefer the collapse/expand approach to grouping. I'm using
non-grouped search now but would like to switch to grouped and
collapse/expand could work for my use case, but the effective defeat of
query caching for any faceted application seems pretty problematic and I'd
be hesitant to switch over if I'm effectively losing query caching by doing
so. My query cache hit rate is reasonably high.
Thanks!
Ron
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-facets-and-qtime-caching-issue-tp4319759p4320114.html
Sent from the Solr - User mailing list archive at Nabble.com.
