[
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: [email protected]
For additional commands, e-mail: [email protected]
