Hi Joel,
Thanks for your reply.
For the "having" expression, it says that it requires a BooleanEvaluator.
Which means I can only use it to filter if there is Boolean Evaluator, and
not if it is just a normal query?
And yes, it will be good to support filter queries with fetch. Should I put
that
We are talking about fewer collections,so that won't be an issue.
The problem comes when - using the proposed setup - I want to send a query
across all those collections and get properly ranked results. Each
collection has its own IDF etc, so the scores are not comparable. This means
that most pr
John:
The patch certainly doesn't apply cleanly to 5.4. that said, there
were just a few conflicts so that part doesn't look too bad. I don't
know anyone who has actually backported it that far so it's unexplored
territory.
Note that the patch was generated for 6x which requires Java 1.8
whereas
Eric,
We're using Solr 5.5.4 and aren't really eager to change at this moment...
Off the top of your head - what probability that the patch here:
https://issues.apache.org/jira/browse/SOLR-10524
... will work in 5.5.4 with minimal difficulty?
For example, were there other classes introduced in
How do I get SortedSetDocValues from index by field name?
I try it and it works for me but I didn't understand why to use
leaves.get(0)? What does it mean? (I saw such using in
TestUninvertedReader.java of SOLR-6.5.1):
*Map mapping = new HashMap<>();
mapping.put(fieldName, UninvertingReader.Type.
Going with single cluster having multiple collections (for each client) is
what I would try. How many clients do you have? If 10K, mean 10K
collections and then how many documents, their size etc. you will need to
come up with to nail down #machines and their memory/cpu requirements.
Going with si
I'm trying to setup a multi-tenant Solr cluster (v6.5.1) which must meet the
following requirements. The tenants are different customers with similar
type of data.
* Ability to query per client but also across all clients
* Don't want to hit all shards for all type of requests (per client, across
Well, segments won't be merged except during active indexing,
specifically when you issue a commit. Do you have any commit settings
specified.
You can't tell much by raw heap size since you don't control when
garbage collections occur. What happens if you attach, say, jconsole
to it and force a GC
Currently you cannot specify a query for fetch. You can filter tuples
emitted by fetch by wrapping it in a "having" expression.
In the future I think it makes sense to support filter queries with fetch.
Joel Bernstein
http://joelsolr.blogspot.com/
On Tue, Jun 13, 2017 at 4:46 AM, Zheng Lin Edwin
Hi,
We are using master slave architecture, here are the observations:
1. Heap size and connections on slave are increasing and leading to more
query time.
2. We are noticing on solr admin UI that segment count is huge and also no
merging is taking place.
3. We have not made any changes and a n
Inner purely negative queries match nothing. A query is about matching, and
skipping over things that don’t match. The fix is when using (-something) to
do (*:* -something) to match everything and skip the negative clause items.
In your example, try fq=((*:* -documentTypeId:3) AND companyId:29
Hi All,
Appreciate if anyone can help to understand index side synonyms implementation
Regards,
Sweta Parekh
Search / CRO - Associate Program Manager
From: Sweta Parekh
Sent: Monday, June 05, 2017 8:46 PM
To: 'solr-user@lucene.apache.org'
Subject: Managed Synonyms query
Hi All,
We are using m
Hi,
For the Streaming expression on Fetch, is it possible to have set the q
parameter for the "addresses" collection?
In the below example from the Solr Documentation, it is only setting the q
parameter for the "people" collection.
I'm using Solr 6.5.1.
fetch(addresses,
search(people, q="*
Hi Everyone,
I have hit a weird behavior of Boolean Query, when I am
running the query with below param’s it’s not behaving as expected. can
you please help me understand the behavior here?
q=*:*&fq=((-documentTypeId:3)+AND+companyId:29096)&version=2.2&start=0&rows=10&indent=on
14 matches
Mail list logo