You will run into significant problems if, when returning "all
results", you return large result sets. For regular queries I like to
limit the return to 100, although 1,000 is sometimes OK.
Millions will blow you out of the water, use CursorMark or Streaming
for very large result sets. CursorMark gets you a page at a time, but
efficiently and Streaming doesn't consume huge amounts of memory.
And assuming you could possible return 1M rows, say, what would the
user do with it? Displaying in a browser is problematic for instance.
Best,
Erick
On Wed, Sep 12, 2018 at 5:54 AM Shawn Heisey <apa...@elyograg.org> wrote:
>
> On 9/12/2018 5:47 AM, Dwane Hall wrote:
> > Good afternoon Solr brains trust I'm seeking some community advice if
> > somebody can spare a minute from their busy schedules.
> >
> > I'm attempting to use the switch query parser to influence client search
> > behaviour based on a client specified request parameter.
> >
> > Essentially I want the following to occur:
> >
> > -A user has the option to pass through an optional request parameter
> > "allResults" to solr
> > -If "allResults" is true then return all matching query records by
> > appending a filter query for all records (fq=*:*)
> > -If "allResults" is empty then apply a filter using the collapse query
> > parser ({!collapse field=SUMMARY_FIELD})
>
> I'm looking at the documentation for the switch parser and I'm having
> difficulty figuring out what it actually does.
>
> This is the kind of thing that is better to handle in your client
> instead of asking Solr to do it for you. You'd have to have your code
> construct the complex localparam for the switch parser ... it would be
> much easier to write code to insert your special collapse filter when it
> is required.
>
> > Everything works nicely until I move from a single node solr instance (DEV)
> > to a clustered solr instance (PTST) in which I receive a null pointer
> > exception from Solr which I'm having trouble picking apart. I've
> > co-located the solr documents using document routing which appear to be the
> > only requirement for the collapse query parser's use.
>
> Some features break down when working with sharded indexes. This is one
> of the reasons that sharding should only be done when it is absolutely
> required. A single-shard index tends to perform better anyway, unless
> it's really really huge.
>
> The error is a remote exception, from
> https://myserver:1234/solr/my_collection_ptst_shard2_replica_n2. Which
> suggests that maybe not all your documents are co-located on the same
> shard the way you think they are. Is this a remote server/shard? I am
> completely guessing here. It's always possible that you've encountered
> a bug. Does this one (not fixed) look like it might apply?
>
> https://issues.apache.org/jira/browse/SOLR-9104
>
> There should be a server-side error logged by the Solr instance running
> on myserver:1234 as well. Have you looked at that?
>
> I do not know what PTST means. Is that important for me to understand?
>
> Thanks,
> Shawn
>
