Re: Optimizing fq query performance

I did a few tests with our instance solr-7.4.0 and field:* vs field:[* TO *] doesn't seem materially different compared to has_field:1. If no one knows why Lucene optimizes one but not another, it's not clear whether it even optimizes one to be sure. On Wed, Apr 17, 2019 at 4:27 PM Shawn Heisey

Re: Solr8.0.0 date search issue

Added the following in the Schema file - And modified to Still the following not working NOW NOW-7DAYS NOW-30DAYS The following has started working fq=date_upload:[2018-12-01 TO 2019-04-17] On Thu, 18 Apr 2019 at 08:15, Anuj Bhargava wrote: > I have an issue while searching on the Date

Solr8.0.0 date search issue

I have an issue while searching on the Date field date_upload My Schema file has the following entry for DATE Field ** My data-config.xml has the following entry - ** *The following do not work -* fq=date_upload:NOW (does not work)

Re: JSON Facet query to retrieve count all collections in Solr 8.0.0

Hi Jason, The same problem still persist after restarting my Solr nodes. The only time the problem didn't occur is when I disabled the basic authentication. I have tried with a few "/select?q=*:*", and they do not exhibit the same problem. Even the similar query with only 1 shard does not have

Re: Replica becomes leader when shard was taking a time to update document - Solr 6.1.0

Specifically a _leader_ being put into the down or recovering state is almost always because ZooKeeper cannot ping it and get a response back before it times out. This also points to large GC pauses no the Solr node. Using something like GCViewer on the GC logs at the time of the problem will

Blockjoin with Filter Query on Child Doc Result Set

Hello, Is there a good way to do Solr Parent blockjoins with filter queries on children (i.e. the results of the children query set affect the filter on the children of the filter query)? Solr has a convenient way of doing filter queries on the result set of parent block joins. E.g. |q={!parent

Re: Optimizing fq query performance

On 4/17/2019 1:21 PM, John Davis wrote: If what you describe is the case for range query [* TO *], why would lucene not optimize field:* similar way? I don't know. Low level lucene operation is a mystery to me. I have seen first-hand that the range query is MUCH faster than the wildcard

Re: Optimizing fq query performance

If what you describe is the case for range query [* TO *], why would lucene not optimize field:* similar way? On Wed, Apr 17, 2019 at 10:36 AM Shawn Heisey wrote: > On 4/17/2019 10:51 AM, John Davis wrote: > > Can you clarify why field:[* TO *] is lot more efficient than field:* > > It's a

Re: Optimizing fq query performance

On 4/17/2019 10:51 AM, John Davis wrote: Can you clarify why field:[* TO *] is lot more efficient than field:* It's a range query. For every document, Lucene just has to answer two questions -- is the value more than any possible value and is the value less than any possible value. The

Re: JSON Facet query to retrieve count all collections in Solr 8.0.0

Agreed, I'd be surprised if this behavior was specific to JSON Faceting. Though I'm surprised it's happening at all, so... Anyway, that's easy for you to test though. Try a few "/select?q=*:*" queries and see whether they also exhibits this behavior. One other question: does the behavior

Re: Optimizing fq query performance

Can you clarify why field:[* TO *] is lot more efficient than field:* On Sun, Apr 14, 2019 at 12:14 PM Shawn Heisey wrote: > On 4/13/2019 12:58 PM, John Davis wrote: > > We noticed a sizable performance degradation when we add certain fq > filters > > to the query even though the result set

Re: Cannot set pollInterval in SolrCloud for PULL or TLOG replica

It looks like `/solr//replication?command=disablepoll` doesn't work in cloud mode so there's no way to change settings for interval as well as to say replicas to stop polling. My own conclusion: if you have bulk updates and commit with openSearcher=true only at the end PULL/TLOG replicas isn't

Re: Replica becomes leader when shard was taking a time to update document - Solr 6.1.0

On 4/17/2019 6:25 AM, vishal patel wrote: Why did shard1 take a 1.8 minutes time for update? and if it took time for update then why did replica1 try to become leader? Is it required to update any timeout? There's no information here that can tell us why the update took so long. My best

Re: Upgrading Solr 6.3.0 to 7.5.0 without having to re-index

On 4/17/2019 3:52 AM, Ritesh Kumar wrote: Field type in old configuration - string (solr.StrField) indexed and stored set to true. Field type in new configuration - solr.SortableTextField (docValues enabled) On your schema, you have changed the field class -- from StrField to

Re: Understanding Performance of Function Query

This does indeed reduce the time. but doesn't quite do what I wanted. This approach penalizes the docs based on "coord" factor. In other words, for a doc with scores=5 on just one query (and nothing on others), the resulting score would now be 5/3 since only one clause matches. 1. I wonder why

Re: Cannot set pollInterval in SolrCloud for PULL or TLOG replica

Hi Vadim, thank you seems like we both had similar questions. So I think that all confirms that it's not configurable for now. That's in fact a pity because it only makes sense to use PULL/TLOG replicas in order to save CPU and not reindex docs on every node but current situation with reopening

Replica becomes leader when shard was taking a time to update document - Solr 6.1.0

We have 2 shard and 2 replicas in production server.Somehow replica1 became leader when some commit process was running in shard1. Log :: ***shard1*** 2019-04-08 12:52:09.930 INFO (searcherExecutor-30-thread-1-processing-n:shard1:8983_solr x:productData s:shard1 c:productData r:core_node1)

Upgrading Solr 6.3.0 to 7.5.0 without having to re-index

Hello Team, I have been trying to upgrade Solr 6.3.0 to 7.5.0 and I do not want to re-index. I tried it using the Index Upgrader Tool . The tool did its part and the current index is according to the current file format. The

Re: local paramas only with defType=lucene?

Yup Changes in Solr 7.2: local parameters only parsed when defType is either "lucene" or "func" cf. https://lucene.apache.org/solr/guide/7_3/solr-upgrade-notes.html#solr-7-2 cf. https://issues.apache.org/jira/browse/SOLR-11501 On 17 Apr 2019, at 10:35, Michael Aleythe, Sternwald

local paramas only with defType=lucene?

Hi everybody, is it correct that local parameters ( q={!edismax qf=MEDIA_ID v=283813390} ) in solr only work with the lucene query parser defined for the main query? I tried with dismax/edismax but it did not work. The documentation is not clear on this point. Best regards Michael Aleythe

Re: JSON Facet query to retrieve count all collections in Solr 8.0.0

Hi, For your info, I have enabled basic authentication and SSL in all the 3 versions, and I'm not sure if the issue is more on the authentication side instead of the JSON Facet query? Regards, Edwin On Wed, 17 Apr 2019 at 06:54, Zheng Lin Edwin Yeo wrote: > Hi Jason, > > Yes, that is correct.

Re: "dismax" parameter "bq" filters instead of boosting

I am not sure whether it is a bug or not actually. I never really used dismax. Perhaps others can comment on that. Regards, Alex. On Wed, 17 Apr 2019 at 09:59, Nicolas Franck wrote: > > Ok, thanks for your investigation ;-) That was quick. > > So you consider this as a bug, as it was fixed

Re: Solr nested objects (child documents)

latest. why is that important? -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: "dismax" parameter "bq" filters instead of boosting

Ok, thanks for your investigation ;-) That was quick. So you consider this as a bug, as it was fixed for edismax parser? I thought the parameter q.op only applied to the terms in de main query (parameter "q"), making .. jakarta apache to be interpreted as +jakarta +apache when q.op = AND