[
https://issues.apache.org/jira/browse/SOLR-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14186037#comment-14186037
]
Hoss Man commented on SOLR-6663:
--------------------------------
cut/pasting comments about this from SOLR-6351...
----
[Steve's initial
suggestion|https://issues.apache.org/jira/browse/SOLR-6351?focusedCommentId=14160413&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14160413]...
{quote}
One more question around this, which applies for SOLR-6353 and SOLR-4212 as
well. Should we have a syntax to apply stats/queries/ranges only at specific
levels in the pivot hierarchy? It would reduce amount of computation and size
of response for cases where you only need it at a specific level (usually last
level I guess). Something like:
facet.pivot=\{!stats=s1,s2\}field1,field2
We could us * for all levels, or something like:
facet.pivot=\{!stats=,,s3\}field1,field2,field3
to only apply at 3rd level.
{quote}
[My
reply|https://issues.apache.org/jira/browse/SOLR-6351?focusedCommentId=14160658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14160658]...
{quote}
...
That's a great question ... honestly it's not something i ever really thought
about.
One quick thing i will point out: the size of the response shouldn't really be
a huge factor in our decisions here, because with SOLR-6349 (which i'll
hopefully have a patch for in the next day or so) the response will only need
to include the stats people actually care about, andsask for, so the typical
result size should be much smaller.
But you've got a good point about amount of computation done/returned at levels
that people may not care about ... in my head, it seemed to make sense that the
stats (and ranges, etc...) should be computed at every level just like the
pivot count size -- but at the intermediate levels that count is a "free"
computation based on the size of the subset, and but i suspect you are correct:
may people may only care about having these new stats/ranges/query on the
leaves in the common case.
I'm not really following your suggested syntax though ... you seem to be saying
that in the "stats" local param, commas would be used to delimit "levels" of
the pivot (corresponding to the commas in the list of pivot fields) but then
i'm not really clear what you mean about using "\*" (if that means all levels,
how do you know what tag name to use?
in the original examples i porposed, i was thinking that a comma seperated list
could refer to multiple tag names, wimilar to how the "exlcusions" work -- ie..
{noformat}
facet.pivot={!stats=prices,ratings}category,manufacturer
facet.pivot={!stats=prices,pop}reseller
stats.field={!key=avg_list_price tag=prices mean=true}list_price
stats.field={!tag=ratings min=true max=true}user_rating
stats.field={!tag=ratings min=true max=true}editors_rating
stats.field={!tag=prices min=true max=true}sale_price
stats.field={!tag=pop}weekly_tweets
stats.field={!tag=pop}weekly_page_views
{noformat}
...would result in the "category,manufacturer" pivot having stats on
"avg_list_price, sale_price, user_rating, & editors_rating" while the
"reseller" pivot would have stats on "avg_list_price, sale_price,
weekly_tweets, & weekly_page_views"
Thinking about it now though, if we support multiple tag names on stats.field,
the same thing could be supported like this...
{noformat}
facet.pivot={!stats=cm_s}category,manufacturer
facet.pivot={!stats=r_s}reseller
stats.field={!key=avg_list_price tag=cm_s,r_s mean=true}list_price
stats.field={!tag=cm_s min=true max=true}user_rating
stats.field={!tag=cm_s min=true max=true}editors_rating
stats.field={!tag=cm_s,r_s min=true max=true}sale_price
stats.field={!tag=r_s}weekly_tweets
stats.field={!tag=r_s}weekly_page_views
{noformat}
So ... if we did that, then we could start using "position" info in a comma
seperated list of tag names to refer to where in the pivot "depth" those
stats/ranges/queries should be computed ... the question i have is "should we"
? .. in the context of a facet.pivot param, will it be obvious to folks that
there is a maping between the commas in these local params and hte commas in
hte bod of the facet.pivot param, or will it confuse people who are use to
seeing comma as just a way of delimiting multiple values in tag/ex params?
my opinion: no freaking clue at the moment ... need to let it soak in my brain.
{quote}
> decide rules & syntax for computing stats/ranges/queries only at certain
> levels of a pivot
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-6663
> URL: https://issues.apache.org/jira/browse/SOLR-6663
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
>
> [~smolloy] asked a great question in SOLR-6351...
> bq. One more question around this, which applies for SOLR-6353 and SOLR-4212
> as well. Should we have a syntax to apply stats/queries/ranges only at
> specific levels in the pivot hierarchy? It would reduce amount of computation
> and size of response for cases where you only need it at a specific level
> (usually last level I guess).
> I'm splitting this off into it's own Sub-task for further discussion.
> ----
> For now, the "stats" localparam must be a single tag, and the "work around"
> is to add a common tag to all stats you want to use.
> ie, this will cause an error...
> {noformat}
> stats.field={!tag=tagA}price
> stats.field={!tag=tagB}popularity
> stats.field={!tag=tagB}clicks
> facet.pivot={!stats=tagA,tagB}xxx,yyy,zz
> {noformat}
> but this will work...
> {noformat}
> stats.field={!tag=tagA,tagPivot}price
> stats.field={!tag=tagB,tagPivot}popularity
> stats.field={!tag=tagB,tagPivot}clicks
> facet.pivot={!stats=tagPivot}xxx,yyy,zz
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
