Hi,
What is the difference between solr 3.3 and the trunk ?
I will try 3.3 and let you know the results.
Here the search handler:
explicit
10
mrank:[0 TO 100]
explicit
10
edismax
title^1.05 url^1.2 content^1.7 m_title^10.0
content^18.0 m_
depends on the case.
we have a database here that updates very frequently, so we just added a
field named syncid and set it to the index day. everytime the database
updates it updates the syncid to the current day. after we perform a full
database update, we tell solr to delete all records differe
I'm not sure what the issue could be at this point. I see you've got
qt=search - what's the definition of that request handler?
What is the parsed query (from the debugQuery response)?
Have you tried this with Solr 3.3 to see if there's any appreciable difference?
Erik
On Aug 27, 201
When grouping off the query time ie 3567 ms to 1912 ms . Grouping
increasing the query time and make useless to cache. But same config faster
without shingle still.
We have and head to head test this wednesday tihs commercial search engine.
So I am looking for all suggestions.
On Sat, Aug 27,
hi
we developed a solr and connected to database and getting the
records from database. now we deleted the records in table but iam getting
the old
records in solr... to solve this what we have to do.
how to solve this problem
thanks in advance
--
View this message in context:
http://lu
Please confirm is this is caused by grouping. Turn grouping off, what's query
time like?
On Aug 27, 2011, at 07:27 , Lord Khan Han wrote:
> On the other hand We couldnt use the cache for below types queries. I think
> its caused from grouping. Anyway we need to be sub second without cache.
>
Merlin
Ü encodes to two characters in utf-8 (C39C), and one in iso-8859-1 (%DC) so it
looks like there is a charset mismatch somewhere.
Cheers
François
On Aug 27, 2011, at 6:34 AM, Merlin Morgenstern wrote:
> Hello,
>
> I am having problems with searches that are issued from spiders that
On the other hand We couldnt use the cache for below types queries. I think
its caused from grouping. Anyway we need to be sub second without cache.
On Sat, Aug 27, 2011 at 2:18 PM, Lord Khan Han wrote:
> Hi,
>
> Thanks for the reply.
>
> Here the solr log capture.:
>
> **
>
> hl.fragsize=1
Hi,
Thanks for the reply.
Here the solr log capture.:
**
hl.fragsize=100&spellcheck=true&spellcheck.q=X&group.limit=5&hl.simple.pre=&hl.fl=content&spellcheck.collate=true&wt=javabin&hl=true&rows=20&version=2&fl=score,approved,domain,host,id,lang,mimetype,title,tstamp,url,category&hl.snip
Hello,
I am having problems with searches that are issued from spiders that contain
the ASCII encoded character "ü"
For example in : "Übersetzung"
The solr log shows following query request: /suche/%DCbersetzung
which has been translated into solr query: q=?ersetzung
If you enter the search ter
Karthik,
I sure could be wrong but I never found this.
My search tool implementations (3 thus far, one on solr, all on the web) have
always proceeded with one tool for experts called something like "indexed-view"
which basically remade the indexing process as a "dry-run".
This can also be don
11 matches
Mail list logo