This was one example. Users can even add phrase searches with
wildcards/proximity etc so can't really use stemming.
Sharding is definitely something we are already looking into.
On Wed, Mar 19, 2014 at 6:59 PM, Erick Erickson wrote:
> Yes, that'll be slow. Wildcards are, at best, interesting an
Yes, that'll be slow. Wildcards are, at best, interesting and at worst
resource consumptive. Especially when you're doing this kind of
positioning information as well.
Consider looking at the problem sideways. That is, what is your
purpose in searching for, say, "buy*"? You want to find buy, buyin
Anyone?
On Mon, Mar 17, 2014 at 12:03 PM, Salman Akram <
salman.ak...@northbaysolutions.net> wrote:
> Below is one of the sample slow query that takes mins!
>
> ((stock or share*) w/10 (sale or sell* or sold or bought or buy* or
> purchase* or repurchase*)) w/10 (executive or director)
>
> If a
Below is one of the sample slow query that takes mins!
((stock or share*) w/10 (sale or sell* or sold or bought or buy* or
purchase* or repurchase*)) w/10 (executive or director)
If a filter is used it comes in fq but what can be done about plain keyword
search?
On Sun, Mar 16, 2014 at 4:37 AM,
What are our complex queries? You
say that your app will very rarely see the
same query thus you aren't using caches...
But, if you can move some of your
clauses to fq clauses, then the filterCache
might well be used to good effect.
On Thu, Mar 13, 2014 at 7:22 AM, Salman Akram
wrote:
> 1- SOLR
1- SOLR 4.6
2- We do but right now I am talking about plain keyword queries just sorted
by date. Once this is better will start looking into caches which we
already changed a little.
3- As I said the contents are not stored in this index. Some other metadata
fields are but with normal queries its s
1. What is your solr version? In 4.x family the proximity searches have
been optimized among other query types.
2. Do you use the filter queries? What is the situation with the cache
utilization ratios? Optimize (= i.e. bump up the respective cache sizes) if
you have low hitratios and many eviction
Well some of the searches take minutes.
Below are some stats about this particular index that I am talking about:
Index size = 400GB (Using CommonGrams so without that the index is around
180GB)
Position File = 280GB
Total Docs = 170 million (just indexed for searching - for highlighting
contents
As Hoss pointed out above, different projects have different requirements.
Some want to sort by date of ingestion reverse, which means that having
posting lists organized in a reverse order with the early termination is
the way to go (no such feature in Solr directly). Some other projects want
to c
Its a long video and I will definitely go through it but it seems this is
not possible with SOLR as it is?
I just thought it would be quite a common issue; I mean generally for
search engines its more important to show the first page results, rather
than using timeAllowed which might not even retu
Salman,
It looks like what you describe has been implemented at Twitter.
Presentation from the recent Lucene / Solr Revolution conference in Dublin:
http://www.youtube.com/watch?v=AguWva8P_DI
On Sat, Mar 8, 2014 at 4:16 PM, Salman Akram <
salman.ak...@northbaysolutions.net> wrote:
> The issue
The issue with timeallowed is you never know if it will return minimum
amount of docs or not.
I do want docs to be sorted based on date but it seems its not possible
that solr starts searching from recent docs and stops after finding certain
no. of docs...any other tweak?
Thanks
On Saturday, Ma
: Reason: In an index with millions of documents I don't want to know that a
: certain query matched 1 million docs (of course it will take time to
: calculate that). Why don't just stop looking for more results lets say
: after it finds 100 docs? Possible??
but if you care about sorting, ie: you
I know about numFound. That's where the issue is.
On a complex query that takes mins I think there would be a major chunk of
that spent in calculating "numFound" whereas I don't need it. Let's say I
just need first 100 docs and then want SOLR to STOP looking further to
populate the "numFound".
Le
you limit the number of results by using the rows parameter. You query
however may hit more documents (stored in numFound of the response) that
what will be returned back to you as rows prescribes.
On Fri, Mar 7, 2014 at 11:48 AM, Salman Akram <
salman.ak...@northbaysolutions.net> wrote:
> All,
On 7 March 2014 15:18, Salman Akram wrote:
> All,
>
> Is it possible to get partial counts in SOLR? The idea is to get the count
> but if its above a certain limit than just return that limit.
>
> Reason: In an index with millions of documents I don't want to know that a
> certain query matched 1
16 matches
Mail list logo
