Hi there,
We noticed a sizable performance degradation when we add certain fq filters
to the query even though the result set does not change between the two
queries. I would've expected solr to optimize internally by picking the
most constrained fq filter first, but maybe my understanding is wron
More constrained but matching the same set of documents just guarantees
that there is more information to evaluate per document matched.
For your specific case, you can optimize fq = 'field1:* AND field2:value'
to &fq=field1:*&fq=field2:value
This will at least cause field1:* to be cached and reuse
Hello!
I am new to SOLR. This is my field type definition:
> stored="true" multiValued="true" omitTermFreqAndPositions="true"
> omitNorms="true" />
One use-case we have is to lookup multiple myid with an OR like
> fq=myid:(1 2 3 4..)
I wish to know which entry in the fq matched this document.
Also note that field1:* does not necessarily match all documents. A document
without that field will not match. So it really can’t be optimized they way you
might expect since, as Yonik says, all the terms have to be enumerated….
Best,
Erick
> On Apr 13, 2019, at 12:30 PM, Yonik Seeley wrote:
Thanks for your reply.
2> In production, lots of documents come for indexing within a second.If i do
hard commit interval to 60 seconds then in less times open searchers when hard
commit execute. Is it ohk for performance?
3> soft commit 60 second we can not do as of now because our product imp
Hi,
I think your requirement of exporting back to CSV is fine but it's quite
normal for there to be some transformation steps on input and/or output...
and that such steps you mostly do yourself (not Solr). That said, one
straight-forward solution is to have your spatial field be redundant with
t
Specifically, the pre-processing can be done with
UpdateRequestProcessors:
https://lucene.apache.org/solr/guide/7_2/update-request-processors.html
In your case, you probably want to chain
*) CloneUpdate:
http://www.solr-start.com/javadoc/solr-lucene/org/apache/solr/update/processor/CloneFieldUpdat
> field1:* is slow in general for indexed fields because all terms for the
> field need to be iterated (e.g. does term1 match doc1, does term2 match
> doc1, etc)
This feels like something could be optimized internally by tracking
existence of the field in a doc instead of making users index yet an
