Re: Query parser and default operator

> soon. Feel free to step down through the source and see why the > difference is there (patches welcome!). > > > On Wed, Nov 9, 2016 at 11:26 PM, Pawel Rog wrote: > > Hi Dawid, > > Thanks for your email. It seems StandardQueryParser is free from > > this unexpected

Re: Query parser and default operator

dump(sqp.parse("foo AND bar OR baz", "field_a")); > sqp.setDefaultOperator(StandardQueryConfigHandler.Operator.OR); > dump(sqp.parse("foo AND bar OR baz", "field_a")); > > I get the same result: > > BooleanQuery: +field_a:f

Re: Query parser and default operator

; Erick > > On Wed, Nov 9, 2016 at 1:37 AM, Pawel Rog wrote: > > Hello , > > I have a query `foo AND bar OR baz`. When I use "AND" as a default > operator > > this is the resulting Lucene query: > > > > `+test:foo test:bar test:baz` > >

Query parser and default operator

Hello , I have a query `foo AND bar OR baz`. When I use "AND" as a default operator this is the resulting Lucene query: `+test:foo test:bar test:baz` When I use "OR" this is the resulting query `+test:foo +test:bar test:baz` I expected these two return exactly the same Lucene query because I

Slow doc values merging

Hi, I use Elasticsearch with very simple schema. Only one date field is indexed. Some of document also contain a couple of single-term string fields which are also indexed. Index contain 10 unique string fields. Moreover I have about 500 different numeric fields. I don't index this numeric fields

Re: Query with many clauses

if you can > share some information I'd love to know: > > what kind of things are you searching? > how many terms do your larger queries have? > do the query terms overlap among your queries? > > -Mike Sokolov > > > On 10/28/14 9:40 PM, Pawel Rog wrote: > >&g

Query with many clauses

Hi, I have to run query with a lot of boolean should clauses. Queries like these were of course slow so I decided to change query to filter wrapped by ConstantScoreQuery but it also didn't help. Profiler shows that most of the time is spent on seekExact in BlockTreeTermsReader$FieldReader$SegmentT

Re: Query rewriting - caching rewritten quries

index". I thought that I will be able to reuse the same instance of rewritten query in all MemoryIndex instances but now I see it is not possible. MemoryIndex creates new MemoryIndexReader in each createSearcher call. -- Paweł On Thu, Jul 3, 2014 at 7:40 AM, Pawel Rog wrote: > Hi, >

Re: Query rewriting - caching rewritten quries

Hi, Thank you for your response Chris. I see good news that I can pre-build rewritten queries for a given IndexReader and then use it in the same IndexReader. Can you tell me how I can achieve this? I see each Query has rewrite method which takes IndexReader as an argument. The only thing is just

Query rewriting - caching rewritten quries

Hi, In the system which I develop I have to store many query objects in memory. The system also receives documents. For each document MemoryIndex is instantiated. I execute all stored queries on this MemoryIndex. I realized that searching over MemoryIndex takes much time for query rewriting. I'm w

Re: createNormalizedWeight

Mon, Jun 30, 2014 at 3:24 PM, Pawel Rog wrote: > Hi, > Thank you Uwe. I see mostly ConstantScoreQuery, BooleanQuery and > FilteredQuery. Maybe it is quite cheap for MI but I execute quite many > queries on it and I was looking for optimizations. > > -- > Paweł > > > O

Re: createNormalizedWeight

llee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: ppp.pawel...@gmail.com [mailto:ppp.pawel...@gmail.com] On > > Behalf Of Pawel Rog > > Sent: Monday, June 30, 2014 2:26 PM > > To: ja

createNormalizedWeight

Hi, I'm running queries over memory index and see in profiler significant CPU usage on method createNormalizedWeight. Most of the time is spent on rewrite method. Is it any way to avoid it or optimize to reduce CPU usage on createNormalizedWeight? Scoring is not important for me at all. It only wa