.
Why coreClosedListeners increased to such high number in a single day?
On Mon, 03 Jun 2019 18:21:34 +0800 Adrien Grand wrote
And do you call release on every searcher that you acquire?
On Mon, Jun 3, 2019 at 11:47 AM alex stark <mailto:alex.st...@zoho.com> wrote:
&
Hi Adrien,
I didn't directly open readers. It is controlled by searcher manager.
On Mon, 03 Jun 2019 16:32:06 +0800 Adrien Grand wrote
It looks like you are leaking readers.
On Mon, Jun 3, 2019 at 9:46 AM alex stark <mailto:alex.st...@zoho.com.invalid>
wrot
Hi experts,
I recently have memory issues on Lucene. By checking heap dump, most of them
are occupied by SegmentCoreReaders.coreClosedListeners which is about nearly
half of all.
Dominator Tree
num retain size(bytes) percent percent(live) class Name
--
seriously look at putting the fields you want in docValues=true fields
and pulling from there. The entire Streaming functionality is built on this and
is quite fast. Best, Erick On Mon, Aug 27, 2018 at 7:35 AM
wrote: > > can you post your query string? > > Best >
> > On 8/
machine? no net latency in between? Best On 8/27/18 10:14 AM, alex stark wrote:
> quite small, just serveral simple short text store fields. The total index
size is around 1 GB (2m doc). On Mon, 27 Aug 2018 22:12:07 +0800
wrote Alex,- how big are those docs? Best regards
On 8/27/18 10
quite small, just serveral simple short text store fields. The total index size
is around 1 GB (2m doc). On Mon, 27 Aug 2018 22:12:07 +0800
wrote Alex,- how big are those docs? Best regards
On 8/27/18 10:09 AM, alex stark wrote: > Hello experts, I am wondering is there
any way
Hello experts, I am wondering is there any way to improve document fetching
performance, it appears to me that visiting from store field is quite slow. I
simply tested to use indexsearch.doc() to get 2000 document which takes 50ms.
Is there any idea to improve that?
In Lucene 7.x, CollapsingTopDocsCollector is removed, is there any replacement
of it?
Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail:
u...@thetaphi.de > -Original Message- > From: alex stark
> Sent: Thursday, August 9, 2018 9:12 AM > To: java-user
> Cc: java-user@lucene.apache.org > Subject: Re:
Legacy filter strategy in Lucene 6
strategies still
exist internally, but BooleanQuery decides which one to use automatically based
on the cost API (cheaper clauses run first) and whether sub clauses produce
bitset-based or postings-based iterators. Le mer. 8 août 2018 à 09:46, alex
stark a écrit : > As FilteredQuery are remo
As FilteredQuery are removed in Lucene 6.0, we should use boolean query to do
the filtering. How about the legacy filter strategy such as
LEAP_FROG_FILTER_FIRST_STRATEGY or QUERY_FIRST_FILTER_STRATEGY? What is the
current filter strategy? Thanks,
LUCENE-8396 looks pretty good for LBS use cases, do we have performance result
for this approach? It appears to me it would greatly reduce terms to index a
polygon, and how about search performance? does it also perform well for
complex polygon which has hundreds or more coordinates?
12 matches
Mail list logo
