You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2015/02/18 00:54:12 UTC
[jira] [Commented] (SOLR-7116) Facet refinement shard request
should disable other faceting types
[ https://issues.apache.org/jira/browse/SOLR-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325154#comment-14325154 ]
Hoss Man commented on SOLR-7116:
--------------------------------
skimming the patch looks ok to me ... one point to clarify...
bq. ... furthermore, facet.field and facet.pivot have their own dedicated refinement requests and so a facet.field request should not have options for facet.pivot. ...
that's not entirely true. The point behind a lot of the shard request logic is to try and _share_ requests to the shards whenever possible. just like we piggy back facet facet refinement on PURPOSE_GET_FIELDS if we can find one, we also try to combine facet.field refinement with facet.pivot refinement if both are in use.
so for example, if you have a request with {{facet.field=XX&facet.pivot=YY,ZZ}} then you should see one request each shard with both facet.field=XX and facet.pivot=YY refinements requested at the same time -- then once YY has been refined, a second request to every shard with facet.pivot=YY,ZZ refinements. (ie: only 2 total refinement request to each shard, not 3)
I _think_ from looking at your patch, this should still be true? did you try this in your manual tests?
bq. I guess I could add a proper test for this by examining debug=track.
I've thought about trying to do whitebox tests to verify that a single cloud request triggers the expected shard requests, but i could never figure out a decent idea for how to do it w/o a lot of complex "mocking" up of solr ... if you've got an idea in mind, please open an issue with your thoughts.
> Facet refinement shard request should disable other faceting types
> ------------------------------------------------------------------
>
> Key: SOLR-7116
> URL: https://issues.apache.org/jira/browse/SOLR-7116
> Project: Solr
> Issue Type: Improvement
> Components: faceting
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 5.1
>
> Attachments: SOLR-7116__facet_refinement_opt.patch
>
>
> While examining FacetComponent in the process of adding the new facet.heatmap faceting type, I observed that distributed shard refinement requests were built by copying the existing parameters and then modifying ones pertinent to facet.field or facet.pivot depending on the type of refinement requests (which in turn only happens some of the time, not too often). Those are the only types of faceting that have a refinement phase. These refinement requests _should not_ have facet.query, facet.date, facet.range, facet.interval, or facet.heatpmap since they don't participate in refinement... and furthermore, facet.field and facet.pivot have their own dedicated refinement requests and so a facet.field request _should not_ have options for facet.pivot. But this isn't taken care of, just facet.query is removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org