king
> something), then it's possible that 6.4.2 was more performant mainly
> because edismax was completely ignoring the more complex phrase
> queries generated by analyzeGraphPhrase(...).
>
> I'll be curious to hear what you find, and eager to be corrected if
> the abo
Hi Solr experts,
We're in the process of upgrading SolrCloud from 6.4.2 to 8.3.1, and our
performance testing is consistently showing search latencies are measurably
higher in 8.3.1, for certain kinds of queries it may be as much as 200 ms
higher on average.
We've seen this now in 2 different env
this angle, so please ignore this for now.
On Tue, Jan 22, 2019 at 11:16 AM Elaine Cario wrote:
> We're preparing to upgrade from Solr 6.4.2 to Solr 7.6.0, and found an
> inconsistency in scoring. It appears that term boosts in the query are not
> applied in Solr 7.
>
> The
We're preparing to upgrade from Solr 6.4.2 to Solr 7.6.0, and found an
inconsistency in scoring. It appears that term boosts in the query are not
applied in Solr 7.
The query itself against both versions is identical (removed un-important
params):
("one"^1) OR ("two"^2) OR ("three"^3)
edismax
max
I'm just catching up on reading solr emails, so forgive me for being late
to this dance
I've just gone through a project to enable CDCR on our Solr, and I also
experienced a small period of time where the commits on the source server
just seemed to stop. This was during a period of intense ex
et collection was _assumed_ to be the same as the source?
> >
> > You're right, SOLR-8389 (and associated) should address this
> > but I don't know what the progress is on that. Seems like
> > a reasonable default in any case.
> >
> > Erick
> >
> &
We've recently been exploring options for disaster recovery, and took a
look at CDCR for our SolrCloud(s). It seems to meet our needs, but we've
stumbled into a couple of issues with configuration.
The first issue is that currently CDCR is configured as a request handler
in solrconfig, but becaus
Hi All,
Normally, when we set up a SolrCloud environment, we put a load balancer in
front of the Solr nodes, which we use for sending queries (HttpSolrServer),
and use CloudSolrServer (with the IPs for the zookeeper ensemble nodes) for
sending indexing operations.
Recently we embarked on a projec
I need some clarity on atomic vs in-place updates. For atomic I understand
that all fields need to be stored, either explicitly or through docValues,
since the entire document is re-indexed.
For in-place updates, the documentation states that only the fields being
modified are updated, but does t
Oh, never mind. Apparently staring at logs has led to blindness...I do see
the "master" query with the full elapsed time and hit count, and indeed,
there is a parameter "_" with some tracking number which links all the
queries together.
On Thu, Sep 22, 2016 at 7:32 PM,
We're in the process of upgrading from SolrCloud 4.10 to 5.5, and we
noticed a change in how distributed queries get logged.
In Solr 4.10 we noted that the original node receiving the query logged the
query with a full hit count and elapsed time for the entire query, using
the original request han
Anil,
I've seen situations where if there was a problem with a specific query,
and every shard responds with the same error, the actual exception gets
hidden by a "No live SolrServers..." exception. We originally saw this
with wildcard queries (when every shard reported a "too many expansions...
Mugeesh,
I was quite stumped, figured I'd move on to other emails, and the very next
email described the issue you are having (if you remove the effect of the
Solr Server exception bug).
Here's a link to that email chain:
http://markmail.org/search/?q=docvalues%20error#query:docvalues%20error%20
You may be bumping into this bug:
https://issues.apache.org/jira/browse/SOLR-7951. Can you try a simple
query (no grouping) and see if Solr responds?
On Tue, Feb 23, 2016 at 11:57 AM, Mugeesh Husain wrote:
> Yes, all of the shards in a live state. I guess may be there will be
> docvalues type N
14 matches
Mail list logo
