Huge FacetArrays while using SortedSetDocValuesAccumulator

Hello, We are working with large lucene 4.3.0 index and using SortedSetDocValuesFacetFields for creating facets and SortedSetDocValuesAccumulator for facet accumulation. We couldn't use a taxonomy based facet implementation (We use MultiReader for searching and our indices is composed of mult

Re: Huge FacetArrays while using SortedSetDocValuesAccumulator

partitions can help. But for that you need to use the sidecar taxonomy index. Shai On Mon, Aug 26, 2013 at 11:45 PM, Krishnamurthy, Kannan < kannan.krishnamur...@contractor.cengage.com> wrote: > Hello, > > We are working with large lucene 4.3.0 index and using > SortedSetDocVal

Index Corruption, lucene 5.0 codec, term posting.

Greetings. We are seeing index corruption on one of our index. The index is 30GB with 169 fields, created using Lucene 5.2.1 and lucene 5.0 codec, no deletes and is optimized. We see an " Invalid vLong detected (negative values disallowed)" while checking the field posting. However the chec

Weird ClassCastException running lucene 5.2.1 on Java 1.8.

Greetings, Recently we port our load test environment to Java 1.8 and since then we are seeing a ClassCastException under heavy load after about 2 hours into our load test. Exception StackTrace below. ava.lang.ClassCastException: [J cannot be cast to [B at org.apache.lucene.util.fst

Re: Weird ClassCastException running lucene 5.2.1 on Java 1.8.

will try compiling Lucene 5.2.1 using JDK 1.8 and see if this issues goes > away. That won't help. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Krishnamurthy, Kannan > [mail

Lucene 6.1.0 index upgrade

Greetings. We are currently using Lucene 6.1.0, our typical index size is ~ 200GB and we are planning to move to Lucene 7.0.0. Our daily indexing workflow currently uses IndexWriter.addIndexes() to add an index(this will be on Lucene 7.0.0) to a copy of the of the 200GB index. Further it cal

Re: Lucene 6.1.0 index upgrade

at slower, since it fully reads and writes the index, but it should work across major versions? Mike McCandless http://blog.mikemccandless.com On Thu, Nov 9, 2017 at 3:59 PM, Krishnamurthy, Kannan < kannan.krishnamur...@cengage.com> wrote: > G

Re: Lucene 6.1.0 index upgrade

be incorrect. Mike McCandless http://blog.mikemccandless.com On Thu, Nov 9, 2017 at 6:46 PM, Krishnamurthy, Kannan mailto:kannan.krishnamur...@cengage.com>> wrote: Hi Mike, It doesn’t work either, it throws “Cannot merge a segment that has been created with major version 6 into this index

Re: Lucene 6.1.0 index upgrade

(). ( Many thanks Mike. On 11/10/17, 1:06 PM, "Krishnamurthy, Kannan" wrote: Will the norms still be a concern if the 6.1.0 index was upgraded using the IndexUpgrader? If not would we upgrade first then fake the index creation version to be 7.0.0 ? Thanks again. Kanna

Slow HNSW creation times.

Greetings, We are experiencing slow HNSW creation times during index merge. Specifically, we have noticed that the HNSW graph creation becomes progressively slow after reaching a certain size. Our indexing workflow creates around 60 indices, each containing approximately 500k vectors. The vect

Re: [EXTERNAL] Re: Slow HNSW creation times.

gh. Maybe your dataset is larger than the > size of your page cache, forcing your OS to read vectors from disk directly? > > If this doesn't sound right, running your application with a profiler would > help identify your merging bottleneck. > > On Fri, Apr 19, 2024 at 4:17 P