s
> sorry for late response. @steve I am using solr 5.2 .
> @greg i am using default mm from config file(According to me it is default
> mm is 1).
>
> Regards,
> Abhishek
>
> On Tue, Apr 4, 2017 at 5:27 AM, Greg Pendlebury >
> wrote:
>
> > eDismax uses 'm
eDismax uses 'mm', so knowing what that has been set to is important, or if
it has been left unset/default you would need to consider whether 'q.op'
has been set. Or the default operator from the config file.
Ta,
Greg
On 3 April 2017 at 23:56, Steve Rowe wrote:
> Hi Abhishek,
>
> Which version
This has come up a lot on the lists lately. Keep in mind that edismax
parses your query uses additional parameters such as 'mm' and 'q.op'. It is
the handling of these parameters (and the selection of default values)
which has changed between versions to address a few functionality gaps.
The most
99 million records and they are correct.
>
> Regards,
> Bernd
>
>
> Am 15.09.2016 um 01:41 schrieb Greg Pendlebury:
> > I'm sorry that's been your experience Bernd. If you do manage to find
> some
> > time it would be good to see some details on these bu
em is solved
> > and the customers and users are happy.
> >
> > I hope that this buggy edismax version is not used in solr 6.x otherwise
> you
> > have the same problems there.
> >
> > Regards
> > Bernd
> >
> >
> > Am 12.09.2016 um 05:
rameter takes precedence over this. ..."
> >
> > What I don't understand is why they change some major internals
> > and don't give any notice about how to keep old parsing behavior.
> >
> > From my point of view the old parsing behavior was correc
ot; or "-" to modify that. Now with q.op AND it is
> modified to "+" as a MUST.
>
> I still get some differences in search results between 4.10.4 and 5.5.3.
> What other side effects has this change of q.op from AND to OR in
> other parts of query handling, parsing
I forgot to mention the tickets:
SOLR-2649 and SOLR-8812
On 9 September 2016 at 13:38, Greg Pendlebury
wrote:
> Under 4.10 q.op was ignored by the edismax parser and always forced to OR.
> 5.5 is looking at the q.op=AND you requested.
>
> There are also some changes to the de
Under 4.10 q.op was ignored by the edismax parser and always forced to OR.
5.5 is looking at the q.op=AND you requested.
There are also some changes to the default values selected for mm, but I
doubt those apply here since you are setting it explicitly.
On 8 September 2016 at 00:35, Mikhail Khlud
cit
> operators
> I don’t know...
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 2. jun. 2016 kl. 05.12 skrev Greg Pendlebury >:
> >
> > I would describe that subtly differently, and I think it is where the
> > differen
> Then from 4.x it did not care about q.op if mm was set explicitly,
> but if mm was not set, then q.op=OR —> mm=0%, q.op=AND —> mm=100%
>
> And from 5.5 it seems as q.op does something even if mm is set...
>
> --
> Jan Høydahl, search solution architect
> Cominvent
But isn't that the default value? In this case the OP is setting mm
explicitly to 2.
Will have to look at those code links more thoroughly at work this morning.
Apologies if I am wrong.
Ta,
Greg
On Wednesday, 1 June 2016, Jan Høydahl wrote:
> > 1. jun. 2016 kl. 03.47 skrev Greg
I don't think it is 8812. q.op was completely ignored by edismax prior to
5.5, so it is not mm that changed.
If you do the same 5.4 query with q.op=OR I suspect it will not change the
debug query at all.
On 30 May 2016 at 21:07, Jan Høydahl wrote:
> Hi,
>
> This may be related to SOLR-8812, but
I've received a request from our business area to take a look at
emphasising ~0 phrase matches over ~1 (and greater) more that they are
already. I can't see any doco on the subject, and I'd like to ask if anyone
else has played in this area? Or at least is willing to sanity check my
reasoning befor
fig
> from ZooKeeper so should be running the same settings. Can you diff
> the listings of the index data directories on a leader vs. replica?
> Might give us some insights to what files the leader has that the
> replicas don't have.
>
> Cheers,
> Tim
>
> On
Hi all,
We launched our new production instance of SolrCloud last week and since
then have noticed a trend with regards to disk usage. The non-leader
replicas all seem to be self-optimizing their index segments as expected,
but the leaders have (on average) around 33% more data on disk. My
assumpt
marks... but:
A) I could be wrong, and
B) I could be talking about parallel in a different way to Mike.
Ta,
Greg
On 18 March 2014 10:24, Yonik Seeley wrote:
> On Mon, Mar 17, 2014 at 7:14 PM, Greg Pendlebury
> wrote:
> > My suspicion is that it won't work in parallel
>
>
sts that
cannot skip content.
Ta,
Greg
On 18 March 2014 09:44, Mike Hugo wrote:
> Cursor mark definitely seems like the way to go. If I can get it to work
> in parallel then that's additional bonus
>
>
> On Mon, Mar 17, 2014 at 5:41 PM, Greg Pendlebury
> wrote:
>
&g
Shouldn't all deep pagination against a cluster use the new cursor mark
feature instead of 'start' and 'rows'?
4 or 5 requests still seems a very low limit to be running into an OOM
issues though, so perhaps it is both issues combined?
Ta,
Greg
On 18 March 2014 07:49, Mike Hugo wrote:
> Than
trics class has a method to return 1
> minute stats but it is not used.
>
> On Mon, Mar 17, 2014 at 10:06 AM, Greg Pendlebury
> wrote:
> > In the codahale metrics library there are 1, 5 and 15 minute moving
> > averages just like you would see in a tool like 'top'.
In the codahale metrics library there are 1, 5 and 15 minute moving
averages just like you would see in a tool like 'top'. However in Solr I
can only see 5 and 15 minute values, plus 'avgRequestsPerSecond'. I assumed
this was the 1 minute value initially, but it seems to be something like
the avera
That was really clear; I just had another read through of the documentation
with that explanation in mind and I can see I went off the rails.
Sorry for any confusion on my part, and thanks for the details.
Ta,
Greg
On 8 March 2014 08:36, Chris Hostetter wrote:
>
> : Thank-you, that all sounds
Thank-you, that all sounds great. My assumption about documents being
missed was something like this:
A,B,C,D
where they are sorted by timestamp first and ID second. Say the first
'page' of results is 'A,B', and before the second page is requested both
documents B + C receive update events and th
"* New 'cursorMark' request param for efficient deep paging of sorted
result sets. See http://s.apache.org/cursorpagination";
At the end of the linked doco there is an example that doesn't make sense
to me, because it mentions "sort=timestamp asc" and is then followed by
pseudo code that sorts b
>
> I couldn't reproduce this but I didn't try too hard either. If you are
> able to isolate a reproducible example then please do report back.
> I'll spend some time to review the related code again to see if I can
> spot the problem.
>
> On Thu, Feb 27, 2014
ddd-6eed, 6eee-7fff]
>
> Have you done any more investigation into why this happened? Anything
> strange in the logs? Are you able to reproduce this in a test
> environment?
>
> On Wed, Feb 19, 2014 at 5:16 AM, Greg Pendlebury
> wrote:
> > We've got a 1
We've got a 15 shard cluster spread across 3 hosts. This morning our puppet
software rebooted them all and afterwards the 'range' for each shard has
become null in zookeeper. Is there any way to restore this value short of
rebuilding a fresh index?
I've read various questions from people with a si
Hi All,
TL;DR version: We think we want to explore Lucene/Solr 4.0 and SolrCloud,
but I’m not sure if there is any good doco/articles on how to make
architecture choices for how to chop up big indexes… and what other general
considerations are part of the equation?
I’m throwing this post ou
Ahh, thanks. I might try a basic commit() then and see, although it's not a
huge deal for me. It occurred to me that two optimize() calls would probably
leave exactly the same problem behind.
On 20 May 2011 09:52, Chris Hostetter wrote:
>
> : Thanks for the reply. I'm at home right now, or I'd t
Thanks for the reply. I'm at home right now, or I'd try this myself, but is
the suggestion that two optimize() calls in a row would resolve the issue?
The process in question is a JVM devoted entirely to harvesting, calls
optimize() then shuts down.
The least processor intensive way of triggering
Hi All,
Just quick query of no particular importance to me, but we did observe this
problem:
http://code.google.com/p/solr-geonames/wiki/DeveloperInstall
"It's worth noting that the build has also been run on Mac and Solaris now,
and the Solr index is about half the size. We suspect the optimize(
>> Sounds good. Please go ahead and make this change yourself.
Done.
Ta,
Greg
On 6 April 2011 22:52, Steven A Rowe wrote:
> Hi Greg,
>
> > I need the servlet API in my app for it to work, despite being command
> > line.
> > So adding this to the maven POM fixed everything:
> >
> >
suspect I'd have to add
some Solr logging config before it would tell me this itself. I only
stumbled on it by accident:
http://osdir.com/ml/solr-user.lucene.apache.org/2009-11/msg00831.html
On 6 April 2011 14:48, Greg Pendlebury wrote:
> Hi All,
>
> I'm hoping this is a reaso
Hi All,
I'm hoping this is a reasonably trivial issue, but it's frustrating me to no
end. I'm putting together a tiny command line app to write data into an
index. It has no web based Solr running against it; the index will be moved
at a later time to have a proper server instance start for respon
I can't reproduce reliably, so I'm suspecting there are issues in our code.
I'm refactoring to avoid the problem entirely.
Thanks for the response though Erick.
Greg
On 8 September 2010 21:51, Greg Pendlebury wrote:
> Thanks,
>
> I'll create a deliberate test t
ch.
>
> To test this, you need to be absolutely sure of two things before you
> search:
> 1> the batch is finished processing
> 2> you've issued a commit after the last document in the batch.
>
> If you're sure of the above and still see the problem, please let us
&
Does anyone know with certainty how (or even if) order is evaluated when
updates are performed by batch?
Our application internally buffers solr documents for speed of ingest before
sending them to the server in chunks. The XML documents sent to the solr
server contain all documents in the order t
ng the parameter onlyMorePopular limits the
suggestions that solr can give you(to ones that return more hits than
the existing query), nothing more.
In short, I believe the answer is No.
On 10/04/2009 09:19 PM, Greg Pendlebury wrote:
> Thanks for the response Christian. I'll modify m
duced by adding the paremeter "spellcheck=true".
Suggestions will be returned regardless of whether there are results.
The only time I believe spelling suggestions might not be included is
when all of the words are spelled "correctly".
On 10/04/2009 07:55 PM, Greg P
Hi All,
If I understand correctly the flag 'onlyMorePopular' encapsulates two
independent behaviours. 1) It runs spell checking across queries that returned
hits. Without the flag spell checking is not run when results are found. 2) It
limits suggestions to terms with higher frequencies.
Is th
40 matches
Mail list logo
