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:
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
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
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:
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
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 =field1:*=field2:value
This will at least cause field1:* to be cached and reused if
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
