It looks like Lucene stores the string names of the posting lists in the
index. How compact is this storage (when there may be a very large number
of posting lists, and the string lengths may be large - for example, I may
have an entry that looks like "Cn:4593846->8957363,485". I've seen other
sy
no option 1 is better than reindexing, but option 2 is the fastest imo.
Shai
On Fri, Jul 5, 2013 at 6:55 PM, Peng Gao wrote:
> Thanks.
>
> Yes, that's the case. I'll try it out.
>
> Is Option 1 more expensive than re-indexing?
>
>
> > -Original Message-
> > From: Shai Erera [mailto:ser
Thanks.
Yes, that's the case. I'll try it out.
Is Option 1 more expensive than re-indexing?
> -Original Message-
> From: Shai Erera [mailto:ser...@gmail.com]
> Sent: Friday, July 05, 2013 8:25 AM
> To: java-user@lucene.apache.org
> Subject: Re: Accumulating facets over a MultiReader
>
Yes, there are two ways to do that. First, I assume that what you want to
do is a.addIndexes(b), and if a document D in b is in a, you don't want to
add it to a, right?
In that case, two options:
Option 1
Iterate on the documents in b (their primary key) and if a doc is found in
a, delete it from
Shai,
Once again, thanks for the help.
Yes, I am re-indexing. Using FacetFields.addFacets() on the doc works.
Given that I need to check the uniqueness before merging an index with facets
into a master, is there better way to it without re-indexing?
Gao Peng
> -Original Message-
> From:
On 07/05/2013 01:27 PM, VIGNESH S wrote:
> Hi,
>
> I think using CompressingStoredFieldsFormat Feature introduced in Lucene
> 4.1 may help reduce index size.
>
> Any other comments and suggestions are welcome in this topic..
>
Do you have access to the original documents, outside Lucene?
If so,
Hi,
I think using CompressingStoredFieldsFormat Feature introduced in Lucene
4.1 may help reduce index size.
Any other comments and suggestions are welcome in this topic..
Thanks and Regards
Vignesh Srinivasan
9739135640
On Thu, Jul 4, 2013 at 6:38 PM, VIGNESH S wrote:
> Hi,
>
> Is it mandat
