[
https://issues.apache.org/jira/browse/SOLR-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097372#comment-14097372
]
Hoss Man commented on SOLR-6121:
--------------------------------
Here's an example from irc (reposted with brett_h's permissions) of exactly the
kind of thinking i'm happy to see happening given the current constraint...
{noformat}
11:24 < brett_h:#solr> is ... sorting strings in Solr pretty much a bad idea?
11:24 < brett_h:#solr> it kills my query, but it's required that I use my
uniqueKey to do a cursorMark
11:30 <@hoss:#solr> kills your query how?
11:30 <@hoss:#solr> memory wise you mean?
11:31 <@hoss:#solr> have you looked into docValues?
11:36 < brett_h:#solr> memory, yeah
11:36 < brett_h:#solr> hoss: ahhh, forgot docvalues on this field
11:36 <@hoss:#solr> you should definitley consider using docValues on your
uniqueKey ... should reduce the memory needs
when sorting
11:36 < brett_h:#solr> thanks
11:39 <@hoss:#solr> brett_h: do you mind if i post a transcrit of this exchange
in SOLR-6121 as an examle of my concerns?
11:39 < brett_h:#solr> fine by me hoss
11:41 < brett_h:#solr> in my case, like the ticket says, I don't care at all
about the tie breaker
11:41 < brett_h:#solr> I do however care about perf :)
11:41 < brett_h:#solr> not sure how I missed docvalues on it, I use them for
all other sorts
11:41 < brett_h:#solr> just wasn't thinking since I literally only want to use
it as a tie breaker
11:41 <@hoss:#solr> brett_h: exactly ... which is why you'd probably like
SOLR-6277, but SOLR-6121 would have screwed
you w/o being obvious why, correct?
11:44 < brett_h:#solr> correct
{noformat}
1) brett knew from the current error message in place that he had to include
his uniqueKey in the sort
2) when he added uniqueKey to his sort, the memory usage went way up (because
of FieldCache) and he could equate that in his head as a direct effect of
adding the uniqueKey to the sort clause (instead of it being done behind the
scenes w/o him knowing)
3) that lead him (admitedly, via asking on irc - but he probably would have
gotten it on his own soon, see his comment about other sort fields) to realize
he should add docValues on his uniqueKey field.
4) if we had SOLR-6277, that would also be a viable option for him -- and
something the current cursorMark error message could suggest as an alternative
to adding the uniqueKey.
which re-iterates my thinking:
* the proposal in this issue seems like a bad idea
* SOLR-6277 seems like a a better idea
> cursorMark should accept sort param without explicit uniqueKey, do implicit
> uniqueKey tie breaker sort under the hood
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6121
> URL: https://issues.apache.org/jira/browse/SOLR-6121
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Minor
> Attachments: SOLR-6121.patch
>
>
> If you are using the cursorMark (deep paging) feature, you shouldn't *have*
> to add the uniqueKey to the sort parameter. If the user doesn't do it, the
> user obviously doesn't care about the uniqueKey order relative to whatever
> other sort parameters they may or may not have provided. So if sort doesn't
> have it, then Solr should simply tack it on at the end instead of providing
> an error and potentially confusing the user. This would be more user
> friendly.
> Quoting Hoss from
> [SOLR-5463|https://issues.apache.org/jira/browse/SOLR-5463?focusedCommentId=14011384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14011384]:
> {quote}
> The reason the code currently throws an error was because i figured it was
> better to force the user to choose which tie breaker they wanted (asc vs
> desc) then to just magically pick one arbitrarily.
> If folks think a magic default is a better i've got no serious objections –
> just open a new issue.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
