On Tue, Jan 3, 2012 at 12:36 AM, Michael Ryan wrote:
> I was wondering... how does the TrieField precisionStep value affect the
> speed of non-range queries and sorting?
>
> I'm assuming that int (precisionStep=0) is no slower than tint
> (precisionStep=8) for these - is that correct? tint is j
I was wondering... how does the TrieField precisionStep value affect the speed
of non-range queries and sorting?
I'm assuming that int (precisionStep=0) is no slower than tint
(precisionStep=8) for these - is that correct? tint is just faster for range
queries?
Is int any faster than tint for
Hi Lance,
This is out of context but still asking you the question .
I implemented TextProfileSignature dedupe as suggested but here is something
weired which I came through while implementing -
I am testing it with two documents and trying to index them .
Please see the below content-
On Mon, Jan 2, 2012 at 9:58 PM, Jason Rutherglen
wrote:
>> It still normally makes sense to have the caches enabled (esp filter and
>> document caches).
>
> In the NRT case that statement is completely incorrect
*shrug*
To each their own. I stand my my statement.
-Yonik
http://www.lucidimagin
> It still normally makes sense to have the caches enabled (esp filter and
> document caches).
In the NRT case that statement is completely incorrect
On Mon, Jan 2, 2012 at 5:37 PM, Yonik Seeley wrote:
> On Mon, Jan 2, 2012 at 1:28 PM, Mark Miller wrote:
>> Right - in most NRT cases (very freq
About bumping MaxBooleanQueries. You can certainly
bump it up, but it's a legitimate question whether the
user is well served by allowing that pattern as opposed
to requiring 2 or 3 leading characters. The assumption
behind the maxBooleanClause restriction is that
when there get to be that many cla
Hi,
I'm reposting my StackOverflow question to this thread as I'm not getting
much of a response there. Thank you for any assistance you can provide!
http://stackoverflow.com/questions/8705600/using-solr-autocomplete-for-addresses
I'm new to SOLR, but I've got it up and running, indexing data vi
Hi,
I'm new to SOLR, but I've got it up and running, indexing data via the DIH,
and properly returning results for queries. I'm trying to setup another
core to run suggester, in order to autocomplete geographical locations. We
have a web application that needs to take a city, state / region, count
Forgot to add, that the time when I DO want the highlight to appear
would be with a query that DOES match the default field.
{!lucene q.op=OR df=text_t} kind_s:doc AND (( field_t:[* TO *] )) cars
Where the term 'cars' would be matched against the df. Then I want the
highlight for it.
If th
Hi Juan,
Setting that parameter produces the same extraneous results. Here is
my query:
{!lucene q.op=OR df=text_t} kind_s:doc AND (( field_t:[* TO *] ))
Clearly, the default field (text_t) is not being searched by this query
and highlighting it would be semantically incongruent with the q
On Mon, Jan 2, 2012 at 1:28 PM, Mark Miller wrote:
> Right - in most NRT cases (very frequent soft commits), the cache should
> probably be disabled.
Did you mean autowarm should be disabled (as it already is in the
example config)?
It still normally makes sense to have the caches enabled (esp fi
Reproduced this both on 3.X and trunk using exampledocs.
If you have an optimized index, then reindex ALL docs with a COMMIT, then there
will be only one segment, probably because all docs in the previous segment
were deleted. Adding just a few docs and COMMITting does not trigger this case.
--
Yeah, the only code path I can see this happening on is:
newSearcher.getIndexReader().getSequentialSubReaders().length == 1
So if you keep issuing commits on an optimized index, it will open a new
Searcher and keep rebuilding the index.
Really, this should probably *only* trigger on an optimize
Hi Darren,
This is the expected behavior. Have you tried setting the
hl.requireFieldMatch parameter to true? See:
http://wiki.apache.org/solr/HighlightingParameters#hl.requireFieldMatch
*Juan*
On Mon, Jan 2, 2012 at 10:54 AM, Darren Govoni wrote:
> Hi,
> Can someone tell me if this is corre
hey, is it possible that during those commits nothing has changed in
the index? I mean are you committing nevertheless there are changes?
if so this could happen since the spellchecker gets a new even that
you did a commit but the index didn't really change. The spellchecker
really only checks if t
Hi
Looks like they strip the -Text for the list. Whole message here:
http://lucene.472066.n3.nabble.com/spellcheck-index-is-rebuilt-on-commit-td3626492.html
Yes, I did restart tomcat.
Thanks
Oliver
Zitat von "Jan Høydahl / Cominvent [via Lucene]"
:
>
>
> Olivier, your log snippets did not ma
On 1/2/2012 5:10 AM, mechravi25 wrote:
My solrconfig.xml file has the following details
320
10
10
I am now adding only one document to the index without optimizing and i
notice that another set of segment files is getting created. In all, I
create index 11 documents individua
On 12/29/2011 3:51 PM, Devon Baumgarten wrote:
N-Grams get me pretty great results in general, but I don't want the results
for this particular search to be fuzzy. How can I prevent the fuzzy matches
from appearing?
Ex: If I search "Albatross" I want "Albert" to be excluded completely, rather
Right - in most NRT cases (very frequent soft commits), the cache should
probably be disabled.
2012/1/2 Tomás Fernández Löbbe
> Yes, soft commit currently clears Solr's caches.
>
> On Mon, Jan 2, 2012 at 12:01 PM, ramires wrote:
>
> > hi
> >
> > After soft-commit with below command all cache ar
Olivier, your log snippets did not make it into the mail. I think the mailing
list strips attachments.
Did you reload core or restart Jetty/Tomcat after your changes?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 2. jan. 2012,
Yes, soft commit currently clears Solr's caches.
On Mon, Jan 2, 2012 at 12:01 PM, ramires wrote:
> hi
>
> After soft-commit with below command all cache are cleared. Is it normal?
>
> curl http://localhost:8984/solr/update -H "Content-Type: text/xml"
> --data-binary ' waitSearcher="false"/>'
>
>
hi
After soft-commit with below command all cache are cleared. Is it normal?
curl http://localhost:8984/solr/update -H "Content-Type: text/xml"
--data-binary ''
--
View this message in context:
http://lucene.472066.n3.nabble.com/soft-commit-tp3626765p3626765.html
Sent from the Solr - User m
Hi,
Can someone tell me if this is correct behavior from Solr.
I search on a dynamic field:
field_t:[* TO *]
I set highlight fields to "field_t,text_t" but I am not searching
specifically inside text_t field.
The highlights for text_t come back with EVERY WORD. Maybe because of
the [* TO
Hi,
I implemented TextProfileSignature dedupe as suggested but here is something
weired which I came through while implementing -
I am testing it with two documents and trying to index them .
Please see the below content-
>>
I bought a Toyota Camry in 2007. After driven 6km,
Hello
We are working with solr 4.0, the spellchecker used is still the classic
IndexBasedSpellChecker. Now every time I do a commit, it rebuilds the
spellchecker index, even though I clearly state a build on optimize. The
configuration in solrconfig looks like this:
I call commits testwise throu
Hi,
I have a few doubts regarding the segment files. I have a optimized data in
my solr core and the following are the files there
{_2ni.fdt,_2ni.fdx,_2ni.fnm,_2ni..frq,_2ni..nrm,_2ni..prx,_2ni..tii,_2ni.tis}
and two other files {segments.gen,segments_2hr}.
My understanding is that those 8 files
Hi Erick,
Thanks a lot for the suggestions. Tried the 3.x solr version and the search
is happening fine. Will reach out in case of any further doubts in the
latest 3.x version.
Thanks.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Problems-while-searching-in-default-field-
Thanks, Erick! That sounds great. I really do have to upgrade.
Chantal
On Sun, 2012-01-01 at 16:42 +0100, Erick Erickson wrote:
> Chantal:
>
> bq: The problem with the wildcard searches is that the input is not
> analyzed.
>
> As of 3.6/4.0, this is no longer entirely true. Some analysis is
>
28 matches
Mail list logo
