> i haven't looked closely into what exactly that "useFactory(null)" call
> does, but it's probably worth getting to the bottom of the failures and
> *IF* it's tied to some specific dir type or codec, using annotations to
> supress them -- rather then just eliminating all directory randomization.
: Current version of Luke supports FS based directory implementations only.
: (I think it will be better if future versions support non-FS based custom
: implementations, such as HdfsDirectoryFactory for users who need it.)
: Disabling the randomization, at least for now, sounds reasonable to me
Don't use that call. You're exactly right, it goes out to disk, reads
the doc, decompresses it (16K blocks minimum per doc IIUC) all just to
get the field. 2,000 in 50ms actually isn't bad for all that work ;).
This sounds like an XY problem. You're asking how to speed up fetching
docs, but not te
Taha,-
can you please simplify your case? You need to narrow down more.
Best regards
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
can you post your query string?
Best
On 8/27/18 10:33 AM, alex stark wrote:
In same machine, no net latency. When I reduce to 500 limit, it takes 20ms, which is also slower
than I expected. btw, indexing is stopped. On Mon, 27 Aug 2018 22:17:41 +0800
wrote yes, it should be less
In same machine, no net latency. When I reduce to 500 limit, it takes 20ms,
which is also slower than I expected. btw, indexing is stopped. On Mon, 27
Aug 2018 22:17:41 +0800 wrote yes, it should be
less than a ms actually for those type of files. index and search on the same
machin
yes, it should be less than a ms actually for those type of files.
index and search on the same 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 Mo
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 to imp
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 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 do
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?
Hey i am trying to create some queries which should work like "where .
and and" in sql.
i have tried boolQuery for that purpose eg;
*boolQueryBuilder.add(new BooleanClause(new FuzzyQuery(new Term(fieldCity,
city), 0), Occur.FILTER));
boolQueryBuilder.add(new BooleanClause(new WildcardQue
Thanks for reporting this Vish, this is a bug indeed. I was able to dig a
bit into why your test fails with delete+add but not with updateDocument
and opened https://issues.apache.org/jira/browse/LUCENE-8466 with some more
context.
Le lun. 27 août 2018 à 07:45, a écrit :
> Hi Lucene Developer co
12 matches
Mail list logo
